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.
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.
01
AI systems make decisions with context they can't explain or audit
02
Consent changes don't propagate — they accumulate as regulatory exposure
03
Erasure requests require proof of inaccessibility — a deletion log is not evidence
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.
its absence becomes a choice someone has to defend.
Each time, a verifiable version was shown to exist — and the old normal became unthinkable. Context governance is approaching its first click.
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. [IACR 2026/1109] 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 irreversible 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 independently verifiable in the STACCR Developer Sandbox today: its published JWKS exposes two certificate verification keys and a dedicated Ed25519 log key, and the sandbox issues a real session-scoped Merkle inclusion proof under the published verification specification. That proof authenticates inclusion in one signed session tree only; it does not establish append-only history, persistence, historical availability, completeness, consistency over time, or non-equivocation. The production architecture is designed to use an append-only transparency log with those properties; that production service remains a pre-GA design item. Claim #1 above does not wait on that: it is 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.
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.
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.
On erasure request — cryptographic lifecycle close
UEK destroyed in the customer's KMS — making every wrapped DEK version permanently unwrappable by construction. Propagation registry queried for every adapter that received the token. Signed ErasureAcknowledgment collected from each. Ed25519-signed erasure 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
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 UEK destroyed in customer's KMS
UEK destruction makes every wrapped DEK version permanently unwrappable — all historical ciphertext inaccessible by construction
Test decryption attempted — confirmed to failProof moment
This is the proof moment: the platform demonstrates it cannot recover the data
Every adapter returns Ed25519-signed ErasureAcknowledgment
Each system in the propagation registry signs for its own compliance
Signed erasure certificate issued
Immutable audit ledger entry with adapter confirmation hashes
See the proof run end to end
Run the unwrap, erasure, and certificate flow in your browser.
Verifiable Erasure Certificate
Sample — redacted, pre-GA format
Issuer
STACCR™ / Context Layer Systems
{
"certificate_id": "cert_01HXYZ9Q2...",
"subject_id": "[REDACTED]",
"destruction_attestation": {
"uek_destroyed": true,
"dek_versions_covered": ["v1", "v2", "v3"],
"destruction_timestamp": "2026-06-11T17:41:57Z",
"hsm_attestation": "Production architecture — pre-GA: FIPS 140-3 L1 (Vault Enterprise FIPS Inside, Leidos attestation, BoringCrypto CMVP cert #4735, verified 5 Aug 2026) — L3: validated Marvell modules — AWS CloudHSM (hsm2m.medium), LS2 HSM Family, CMVP #4703; Azure Key Vault Managed HSM, NITROXIII CNN35XX-NFBE HSM Family, CMVP #4700. See the detailed platform surface for Security Policy, approved-mode, and source requirements (ADR-002)"
},
"test_decryption_result":
"FAILED — token unrecoverable",
"adapter_acknowledgments": [
{ "adapter_id": "adp_crm_01...", "status": "ACKNOWLEDGED", "ed25519": true },
{ "adapter_id": "adp_analytics_02...", "status": "ACKNOWLEDGED", "ed25519": true },
{ "adapter_id": "adp_ai_agent_03...", "status": "ACKNOWLEDGED", "ed25519": true }
],
"issued_at": "2026-06-11T17:42:09Z",
"issuer": "STACCR™ / Context Layer Systems",
"certificate_signature": "ed25519:...",
"jwks_url": "https://keys.contextcontinuitylayer.org/.well-known/jwks.json",
"transparency_log": {
"leaf_hash": "sha256:...",
"leaf_index": 0,
"audit_path": [
{ "side": "right", "hash": "sha256:..." }
],
"tree_size": 5,
"signed_tree_head": {
"version": 1,
"hash_algorithm": "SHA-256",
"tree_size": 5,
"root_hash": "sha256:...",
"timestamp": "...",
"alg": "EdDSA",
"kid": "<production-log-key-id>",
"signature": "ed25519:..."
},
"note": "Production design: append-only transparency-log inclusion proof."
}
}Ed25519-signed · Immutable audit ledger entry · Regulatory evidence
SignedDesign Targets — pre-GA
| Target | Design target |
|---|---|
| UEK destruction | < 60s |
| Adapter acknowledgment | < 5 min |
| Certificate issuance | < 6 min end-to-end |
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.
The Adapter Contract
ErasureAcknowledgment Schema
Every system that integrates with STACCR™ signs a binding contract. Accountability is built into the protocol.
// 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": "ed25519:..." }
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 an Ed25519-signed 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?
Customer-held keys (BYOK). KEK per tenant in customer HSM; UEK per subject in dedicated erasure-key store. For the external Level 3 boundary, AWS CloudHSM hsm2m.medium uses the Marvell LS2 HSM Family, FIPS 140-3 Level 3 under CMVP #4703; Azure Key Vault Managed HSM uses the Marvell NITROXIII CNN35XX-NFBE HSM Family (LiquidSecurity 1), FIPS 140-3 Level 3 under CMVP #4700. The certificates belong to Marvell, not AWS or Microsoft. Each deployment must use the named HSM configuration, the applicable Security Policy, and approved mode. Sources: CMVP #4703 https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4703; AWS deployment mapping https://docs.aws.amazon.com/cloudhsm/latest/userguide/fips-validation.html; CMVP #4700 https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4700; Azure deployment mapping https://learn.microsoft.com/en-us/azure/key-vault/managed-hsm/firmware-update; verified 27 August 2026. STACCR™ is architected to never hold the encryption keys to your data.
2. Can you destroy your own access to my data?
UEK destruction removes STACCR™'s ability to decrypt any context for that subject. The UEK wraps every DEK ever issued — destroying it makes all DEK versions permanently unwrappable by construction, including backups and replicas. The KMS policy enforces this, not application logic.
3. Show me a decryption failing after deletion.
The destruction sequence above includes a test-decryption confirmation step, which runs in your browser via the Web Cryptography API. STACCR is designed to attempt unwrap and decrypt after UEK destruction and to record the confirmed failure as part of the erasure certificate.
4. What does leaving you cost — in time, money, and stranded value?
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?
Architected. The erasure certificate is designed to be signed with Ed25519, with ES256 (ECDSA P-256) as the mandatory alternative. Verification keys are designed to be published at a well-known JWKS endpoint; each certificate is designed to carry a Merkle transparency log inclusion proof. A supervisory authority would be able to verify the certificate using standard public tooling — zero trust in the issuer — including years after issuance and after key rotation. Signing key rotation follows a dual-control HSM ceremony with annual cadence.
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
RoadmapKMS / Secrets
In designKMS deletion semantics differ by vendor — active design-partner workstream. Join as Adapter–ISV partner →
AI Frameworks
RoadmapEnterprise SaaS
RoadmapBuilding 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.
| Specification | Design target |
|---|---|
| Token encryption | AES-256-GCM |
| Key hierarchy | Three-tier: KEK per-tenant (customer HSM) → UEK per-subject (erasure-key store — Vault Transit / CloudHSM) → DEK versioned per payload; erasure destroys the UEK |
| 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. 17GDPR Art. 5(2)CCPA §1798.105 |
| Context layers | 7 — Identity · Behavioral · Temporal · Transactional · Relational · Regulatory · Predictive |
| STACCR™ pillars | 6 |
| UEK 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 (erasure-key store) / DEK versioned per payload. Destroying the UEK makes every DEK version unrecoverable by construction. Design partners select and validate the erasure-key store tier for their environment.
Only proof.
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.
Pre-GASTACCR™ capability statements use designed to and architected for language deliberately. Language transitions to present tense as each capability ships and is independently tested.