Continuity without custody

STACCR^™

The First Neutral Context Governance Platform

Your systems authenticate. They don't govern what happens after — and when a deletion request arrives, none of them can prove the data is gone.

Try the Sandbox →Read the CE Adapter Contract Spec →

↓ Scroll

Models are converging.

What separates them now isn't intelligence.
It's how much of you they hold.

The honest name for that is a context monopoly — and it's being built, quietly, inside every major platform right now. The moat isn't the model anymore. It's the memory of you.

AI systems make decisions with context they can't explain or audit

Consent changes don't propagate — they accumulate as regulatory exposure

Erasure requests require proof of inaccessibility — a deletion log is not evidence

The shift

What if leaving
were free?

Context that moves where it's needed — and disappears, provably, the moment you revoke it. No copies left behind, no stranded value, no permission to ask. That's the difference between context that's given and context that's taken.

Watch it become unrecoverable

The proof — live in your browser

Don't take it on faith.
Watch it become unrecoverable.

A token of your context — sealed under one key.

A real AES-256-GCM key is holding it together.

Why this doesn't reverse

Once something can be proven,
its absence becomes a choice someone has to defend.

Your phone number used to belong to your carrier. Then it didn't.

Encryption used to be a premium feature. Then it was everywhere.

Your bank used to own your data. Then you did.

Each time, a verifiable version was shown to exist — and the old normal became unthinkable. Context governance is approaching its first click.

From hostage
to counterparty.

Systems that earn their place in your life every month — because they no longer hold your memory for ransom. Context that's given is richer than context that's taken.

Some years from now, people will find it strange that it was ever otherwise.

Why STACCR™

Built to be verified, not just trusted

Every claim below routes back to one fact: a party holding only the ciphertext can confirm, on their own, that it no longer decrypts. Everything else follows from that.

Verifiable, not promised

A failed decryption can be confirmed by anyone holding the ciphertext — no auditor, no attestation, no trust in a vendor's word required. Erasure becomes a state of the world, not a log entry claiming a job ran. The guarantee comes from the architecture itself: custody-free and reversible by construction, not by policy.

Reaches where deletion can't

Backups, append-only logs, WORM archives, and replicas are where ordinary deletion breaks down — you can't overwrite what you're structurally forbidden from overwriting. Destroying the key doesn't require touching every copy to invalidate all of them, and withdrawal doesn't depend on every downstream system cooperating.

No custody, no new silo

Tokenized references move through your systems; the underlying data never does. Deploying STACCR doesn't create a new catalog, lineage graph, or metadata store to secure and govern — no new accumulation, and no new breach surface.

A category, not just a product

Access-control tools decide whether data flows. Almost nothing governs what happens to context after access is granted — that gap is the category. CCL is the open specification behind it; STACCR is one implementation, built so the standard can outlive any single vendor, including us.

The signed erasure certificate is designed to be independently verifiable in its own right — today it's signed by STACCR, with cryptographic self-verification (published keys, transparency log) on the near-term roadmap. Claim #1 above doesn't wait on that: it's true the moment the key is gone.

Positioning

Where STACCR™ Sits

Runtime Position

Identity Provider

OIDC · SAML · OAuth

STACCR™

Tokenize · Normalize · Policy check · Audit/Provenance

Applications · Agents · Adapters

CRM · EHR · Analytics · AI frameworks · Automation

What STACCR™ Is Not

Not an identity provider
Not a data warehouse or system of record
Not a CRM or CDP
Not AI memory hoarding
Not a consent banner tool

STACCR™ preserves governed continuity, provenance, and revocation without taking ownership of the underlying data.

It sits between your identity layer and everything downstream — it governs context, it doesn't hoard it. It complements your IdP and data stack; it doesn't replace them.

Why Now

The Market Moment

Reduce regulatory exposure

Designed to turn GDPR Art. 17 and CCPA deletion obligations into a signed, regulator-ready certificate — not a deletion log and a hope.

Deploy AI with confidence

Agents and automations can propagate context without your organization inheriting unprovable deletion liability.

Cut audit cost

Architected so 'where did this data go and who touched it' is a query, not a quarter-long forensic project.

Market timing: EU AI Act record-keeping obligations are phasing in. Agent-to-agent context sharing is multiplying propagation paths. The gap between "we deleted it" and "we can prove it" is becoming a board-level question.

How It Works

The Request Lifecycle

Every context event flows through three governed layers — entry, evaluation, and exit. Nothing moves untracked.

Input Layer

Identity assertion received

Provider-agnostic token minted, claims extracted. Sensitive data stays in the source system — only AES-256-GCM encrypted references cross the platform.

Evaluation + Routing Layer

Token evaluated against tenant policy

Context enriched under policy, propagated to registered adapters via the event broker. Every propagation event is recorded to the registry.

Audit Layer

On erasure request — cryptographic lifecycle close

DEK destroyed in the customer's KMS. Propagation registry queried for every adapter that received the token. Signed ErasureAcknowledgment collected from each. Proof certificate issued.

Every request is governed at entry, enriched under policy, and accountable at exit — nothing moves untracked.

Provable Erasure

Cryptographic Proof, Not a Deletion Log

ACTIVE

ERASURE_SCHEDULED

DELETED

VERIFIED_DESTROYED

Irreversibility enforced at KMS policy level, not application layer

Five-Step Destruction Sequence

Erasure initiated

Data-subject request · consent withdrawal · retention expiry · regulatory order

Per-user DEK destroyed in customer's KMS

All key versions across the key lifecycle destroyed

Test decryption attempted — confirmed to failProof moment

This is the proof moment: the platform demonstrates it cannot recover the data

Every adapter returns signed HMAC-SHA256 ErasureAcknowledgment

Each system in the propagation registry signs for its own compliance

Signed erasure certificate issued

Immutable audit ledger entry with adapter confirmation hashes

✓

Verifiable Erasure Certificate

Sample — redacted, pre-GA format

Issuer

STACCR™ / Context Layer Systems

{
  "certificate_id": "cert_01HXYZ9Q2...",
  "subject_id": "[REDACTED]",
  "dek_versions_destroyed": ["v1", "v2", "v3"],
  "destruction_confirmation_token":
    "[REDACTED — held by customer KMS]",
  "test_decryption_result":
    "FAILED — token unrecoverable",
  "adapter_acknowledgments": [
    { "adapter_id": "adp_crm_01...", "status": "ACKNOWLEDGED", "signed": true },
    { "adapter_id": "adp_analytics_02...", "status": "ACKNOWLEDGED", "signed": true },
    { "adapter_id": "adp_ai_agent_03...", "status": "ACKNOWLEDGED", "signed": true }
  ],
  "issued_at": "2026-06-11T17:42:09Z",
  "issuer": "STACCR™ / Context Layer Systems"
}

HMAC-SHA256 signed · Immutable audit ledger entry · Regulatory evidence

Signed

Design Targets — pre-GA

DEK destruction	< 60s
Adapter acknowledgment	< 5 min
Certificate issuance	< 6 min end-to-end

Regulatory Alignment

GDPR Art. 17 / Art. 5(2) / Art. 32
EU AI Act Art. 12–13
CCPA §1798.105
HIPAA §164.312

When a regulator asks "prove it's gone," the answer is a cryptographically signed certificate covering every system that ever held the data — not a deletion log.

Read the full Erasure architecture

The Adapter Contract

ErasureAcknowledgment Schema

Every system that integrates with STACCR™ signs a binding contract. Accountability is built into the protocol.

ErasureAcknowledgment.json

// ErasureAcknowledgment — returned by every adapter within the SLO window
{
  "erasure_request_id": "uuid-v4",
  "adapter_id": "uuid-v4",
  "token_id": "tok_...",
  "purge_completed_at": "2026-06-11T17:42:09Z",
  "decryption_confirmed_failed": true   // MUST be true — false = SEV incident
  "adapter_audit_log_ref": "https://...",
  "adapter_signature": "hmac-sha256:..."
}

Encrypted references only

Adapters never receive plaintext context — only AES-256-GCM encrypted token references.

Registry registration within 500ms of token receipt

Every adapter propagation is immediately recorded so the erasure registry is complete at deletion time.

Revocation listener with signed acknowledgment on erasure

Adapters must implement the revocation protocol and return a signed HMAC-SHA256 ErasureAcknowledgment within the SLO window.

Adapter contract specification available to design partners → Apply for access

Every integrated system signs for its own compliance — accountability is built into the protocol, not promised in a contract appendix.

Verifiability Rubric

The Standard We Hold Ourselves To

Ask this of any vendor, including us.

Attestation-by-trust can't answer these. Attestation-by-cryptography can. The gap between them is the entire problem this platform is designed to close.

1. Who holds the keys?

Architected

Customer-held keys (BYOK). KEK in customer HSM, per-user DEK in customer KMS. STACCR™ is architected to never hold the encryption keys to your data.

2. Can you destroy your own access to my data?

Architected

DEK destruction removes STACCR™'s ability to decrypt. The platform is designed so that after erasure, it cannot recover the data — the KMS policy enforces this, not application logic.

3. Show me a decryption failing after deletion.

Staging demoAvailable to design partners pre-GA

The five-step destruction sequence above includes a live test-decryption confirmation step. The platform attempts to decrypt after DEK destruction and records the confirmed failure as part of the erasure certificate.

4. What does leaving you cost — in time, money, and stranded value?

GA commitmentDesign-partner term

30-Day Exit Commitment (in effect from GA): any customer can leave with a signed erasure certificate and zero stranded value within 30 days.

Our exit guarantee, in effect from GA

Signed erasure certificate + zero stranded value within 30 days. This is a business commitment, not a spec target.

5. Can a third party verify any of this without trusting you?

Open item — P0

Certificate signing key policy and third-party verification path are P0 open items. We don't have a complete answer yet — see the Engineering Roadmap.

We publish our incomplete answers alongside our complete ones. Pre-GA honesty is the only credible form of proof.

The STACCR™ Framework

Six Capabilities, One Outcome

Context that moves where it's needed and disappears when it must. Grouped by buyer job.

Govern propagation

Tokenized Propagation

Moves signed token references instead of raw data across system boundaries.

Without this

Sensitive payloads replicate unchecked across every downstream system.

Context Orchestration

Coordinates context-aware workflows across services, agents, and enterprise platforms.

Without this

Each system reconstructs fragmented state independently — with no consistency guarantees.

Prove provenance

Secure Architecture

Identity-anchored, zero-trust design with policy-governed propagation and encrypted transport.

Without this

Context flows without access controls, making policy enforcement impossible to audit.

Auditable Provenance

Traceable lineage for every context event, access, transformation, and policy decision.

Without this

'Where did this data go?' becomes a forensic project instead of a query.

Enforce lifecycle

Context Continuity Lifecycle

Preserves context integrity from capture through propagation, update, and expiration.

Without this

Context continuity is lost at every system boundary — agents and workflows start from scratch.

Revocation & Erasure

Cryptographic key destruction with per-adapter confirmation and signed erasure certificates.

Without this

Deletion requests are best-effort API calls — legally exposed and technically unverifiable.

Six capabilities, one outcome: context that moves where it's needed and disappears when it must.

Ecosystem

Adapter & Integration Ecosystem

Designed to work with the identity, key-management, and AI stack you already run — the integration list is a roadmap commitment, not a logo wall.

Identity / Auth

Roadmap

OktaAuth0Azure ADAWS IAMAny OIDC/SAML provider

KMS / Secrets

In design

AWS KMSAzure Key VaultGCP KMSHashiCorp VaultHSM

KMS deletion semantics differ by vendor — active design-partner workstream. Join as Adapter–ISV partner →

AI Frameworks

Roadmap

LangChainAutoGenCrewAIOpenAI Agents SDKAnthropic tool use

Enterprise SaaS

Roadmap

Oracle CloudSAPWorkdaySalesforceMicrosoft 365

Building in one of these categories?

Adapter partners get the contract spec, reference implementation, and certification tooling first. Apply as Adapter–ISV partner →

Technical Specification

Design Targets

Design targets, not production benchmarks. Language transitions to present tense when Phase 1 ships and erasure is tested end-to-end.

Token encryption	AES-256-GCM
Key hierarchy	KEK (customer HSM) + per-user DEK (customer KMS — BYOK)
Auth protocols	OAuth 2.0 · OpenID Connect · SAML · API key
Auth SLA design target	Sub-50ms (stateless middleware)
Audit format	Immutable ledger · trace IDs · policy version · consent snapshot
Erasure standards	GDPR Art. 17 / Art. 5(2) · CCPA §1798.105
Context layers	7 — Identity · Behavioral · Temporal · Transactional · Relational · Regulatory · Predictive
STACCR™ pillars	6
DEK destruction design target	< 60s
Adapter acknowledgment design target	< 5 min
Certificate issuance design target	< 6 min end-to-end

Engineering Roadmap

P0 Open Items — Design Partner Decisions

These are the open items between specification and production. We publish them because the architects we want as partners would find them anyway — and because they are precisely what design partners get to shape.

UEK Indirection — Architecture Resolved by Design

The KMS deletion question (P0 #1) has an architectural resolution: a three-tier hierarchy — KEK per-tenant (customer HSM) / UEK per-user (customer KMS) / DEK versioned per payload. Destroying the UEK makes every DEK version unrecoverable by construction — vendor KMS deletion semantics become non-load-bearing. Design partners select and validate the KMS tier for their environment.

No custody. No copies.
Only proof.

Continuity without custody·Right to erasure, verified

Try the Erasure Engine →Request design partner access

Pre-Phase 1. The in-browser key destruction shown above is real Web Crypto. All platform capabilities are stated as designed-to / architected-for until erasure is tested end-to-end.

Design Partner Program

Apply for Access

Enterprise design partners get the architecture spec, design-partner terms, and the ability to shape the P0 open items. Adapter–ISV partners get the contract spec and certification tooling first.

The First Neutral Context Governance Platform

Built to be verified, not just trusted

Verifiable, not promised

Reaches where deletion can't

No custody, no new silo

A category, not just a product

Where STACCR™ Sits

The Market Moment

The Request Lifecycle

Cryptographic Proof, Not a Deletion Log

ErasureAcknowledgment Schema

The Standard We Hold Ourselves To

Six Capabilities, One Outcome

Adapter & Integration Ecosystem

Design Targets

P0 Open Items — Design Partner Decisions

#1KMS Deletion ArchitectureCriticalWhich KMS vendor is selected and how is per-adapter key destruction sequenced?

#2Propagation Registry Data ModelHighHow does the platform track every adapter that received a given token at erasure time?

#3Key Version RegistryHighAre all historical DEK versions tracked and destroyed — not just the current key?

#4Adapter SDK Reference ImplementationMediumDoes a reference SDK exist for third-party adapters to implement revocation contracts?

Apply for Access