CCL Glossary

Definitions for the key terms used across the deck and whitepaper. Use this to resolve any apparent contradictions — many stem from tiers vs. layers or subsystems vs. contracts.

4-Layer Governance PipelineArchitecture: Describes the runtime request lifecycle inside CCL. Every request passes through four sequential layers: (1) Input — identity assertions are ingested and normalized; (2) Evaluation — a deterministic policy engine makes a single-pass auth/consent decision; (3) Routing & Adapter — the decision is translated and forwarded to the appropriate vendor-specific integration; (4) Audit & Observability — an immutable, HMAC-SHA256-signed record of the decision is written.
4-Tier Deployment TopologyArchitecture: Describes where CCL components physically sit in a deployment: (1) Client-side adapters — thin, system-specific integration points at the edge; (2) Event-driven tokenization middleware — the stateless governance tier that coordinates token references; (3) Distributed token reference store — the versioned governance and audit layer; (4) Authoritative source systems — merchant platforms, IdPs, and CDPs that retain actual data ownership.
7 Context LayersArchitecture: The data taxonomy inside every Context Token Envelope. Each layer carries a different class of governance metadata: (1) Identity — normalized actor references and session binding; (2) Behavioral — activity summaries and anomaly indicators; (3) Temporal — freshness, TTL, and causality signals; (4) Transactional — workflow IDs, approval chains, and provenance; (5) Relational — ownership graphs and delegation relationships; (6) Regulatory — jurisdiction, retention obligations, and purpose binding; (7) Predictive — AI model versions and uncertainty signals.
Architectural InvariantsGovernance: The six non-negotiable design rules stated in the CCL whitepaper: (1) No Credential Handling — CCL never handles authentication credentials; identity providers remain authoritative; (2) No Payments — commerce systems stay authoritative for orders and transactions; (3) No Cross-Tenant Aggregation — tenant data is strictly isolated at all times; (4) Provider-Agnostic Design — CCL works with any IdP, CDN, or SaaS vendor via swappable adapters; (5) Deterministic Governance — every policy evaluation is deterministic and fully replayable; (6) Thin Adapters, Opinionated Core — integration surface is thin adapters at the edge over a stable opinionated core.
Auditable ProvenanceSecurity: One of the six STACCR™ pillars. Every governance decision is recorded as an immutable, HMAC-SHA256-signed audit event with a trace ID, enabling full replay of the policy evidence chain. This provides the 'A' in STACCR™.
CCL(Context Continuity Layer)Core: The infrastructure layer CCL™ builds. CCL sits at Layer 5 in the emerging agentic AI stack — above zero-trust identity and access management (ZT-IAM) layers 1–4 — governing what context is valid, permitted, and provable as it flows across APIs, SaaS platforms, and AI agents. It covers identity resolution, authorization, consent, context state, and auditability.
Context OrchestrationGovernance: One of the six STACCR™ pillars. Refers to CCL's role in governing context workflows across heterogeneous APIs, SaaS platforms, and AI agents — ensuring that the right context reaches the right system under the right policy. Provides the first 'C' in STACCR™.
Context Continuity LifecycleGovernance: One of the six STACCR™ pillars. Refers to CCL's ability to maintain coherent, governed context state across sessions, system boundaries, and agent handoffs — so that governance does not reset or break when context crosses a boundary. Provides the second 'C' in STACCR™.
Context Token Envelope(CTE)Core: The fundamental unit of context in CCL. A cryptographically signed (HMAC-SHA256) and AES-256-GCM-encrypted container that carries governance metadata organized into the 7 Context Layers. The envelope travels with context as it crosses system boundaries; its cryptographic signature ensures tamper evidence and its encryption ensures confidentiality.
Cryptographic Erasure(CE)Security: CCL's mechanism for technically-enforced 'right to erasure.' Rather than hunting down and deleting copies of data, CCL destroys the per-user Data Encryption Key (DEK) via a Key Destruction Workflow. Once the DEK is gone, all data encrypted under it becomes permanently and provably inaccessible — erasure is guaranteed by cryptography, not by policy.
DEK(Data Encryption Key)Security: A per-user (or per-tenant) symmetric key used to encrypt that user's data within CCL. When a user exercises their right to erasure, CCL destroys the DEK via a Key Destruction Workflow, rendering the data permanently inaccessible — this is Cryptographic Erasure.
Event-Driven ArchitectureArchitecture: One of CCL's five design principles. Policy evaluation runs on an asynchronous backbone — stream, queue, replay, outbox — so that governance decisions are kept off the request's critical path. This enables high throughput and decoupled, replayable audit trails.
Five Core ContractsGovernance: The five responsibilities CCL commits to handling for every deployment: (1) Identity Resolution — authoritative actor mapping across providers, sessions, and AI agent identities; (2) Authorization — policy-based access decisions covering roles, scopes, attributes, and conditions; (3) Consent — purpose-scoped, revocable permissions enforced at both ingestion and execution; (4) Context State — a canonical Context Token Envelope representing what is true right now; (5) Auditability — immutable decision logs with trace IDs and replayable policy evidence.
Five Logical SubsystemsArchitecture: The internal functional decomposition of CCL's processing pipeline: (1) Capture — ingesting and accepting context from upstream systems; (2) Normalization — standardizing disparate identity and context formats into a canonical representation; (3) Store — persisting governed context references in the distributed token reference store; (4) Propagation — forwarding token references to downstream systems; (5) Audit — writing immutable decision records.
Identity-AgnosticArchitecture: CCL is designed to work with any Identity Provider (IdP) — Okta, Entra ID, Auth0, Cognito, or others — via swappable adapter contracts. No IdP is assumed or required at the core layer. This corresponds to the whitepaper's 'provider-agnostic design' architectural invariant.
Layer 5Core: CCL's position in the emerging agentic AI stack. The stack is conceived as five layers: layers 1–4 cover zero-trust identity and access management (network, device, workload, and application-level ZT-IAM); Layer 5 is the context governance layer — the new infrastructure category that CCL defines and occupies.
Opinionated Core, Pluggable EdgesArchitecture: One of CCL's five design principles. The core governance contracts are stable and opinionated, ensuring consistent behavior across all deployments. Vendor-specific integration details are contained in thin edge adapters. New vendors integrate by implementing an adapter contract, without forking or altering the core platform.
Revocation & ErasureSecurity: One of the six STACCR™ pillars. Refers to CCL's ability to revoke an active context token (immediately invalidating downstream access) and to enforce erasure via Cryptographic Erasure. Together, these make 'delete my data' and 'revoke this agent's access' technically enforceable operations rather than best-effort processes. Provides the 'R' in STACCR™.
Secure ArchitectureSecurity: One of the six STACCR™ pillars. Refers to CCL's zero-trust foundation: no implicit trust, mutual TLS between all components, AES-256-GCM encryption for all envelope data, and HMAC-SHA256 signing for all audit records. Provides the 'S' in STACCR™.
STACCR™Core: CCL's commercial operational framework, named as an acronym for its six pillars: Secure Architecture, Tokenized Propagation, Auditable Provenance, Context Orchestration, Context Continuity Lifecycle, Revocation & Erasure. STACCR™ is the branded packaging of the CCL architecture for enterprise buyers, translating technical invariants into auditable, compliance-friendly language.
Stateless MiddlewareArchitecture: One of CCL's five design principles. The governance tier (the tokenization middleware layer) carries no session state between requests. This makes it horizontally scalable and allows it to return auth decisions in under 50ms regardless of concurrent load.
Strict Tenant IsolationGovernance: Data and context from one tenant is never aggregated with, or made visible to, any other tenant under any circumstance. This is enforced at the token reference store level, not just by policy. It corresponds to the whitepaper's 'no cross-tenant aggregation' architectural invariant.
Tokenization-FirstSecurity: CCL's core architectural innovation, described as such in the whitepaper. Sensitive data from authoritative source systems never enters CCL directly; CCL works exclusively with AES-256-GCM-encrypted token references that point back to data in the source system. There is therefore no central data store within CCL that could be breached. The deck also highlights this as one of its four positioning invariants, and it underpins the Tokenized Propagation STACCR™ pillar.
Tokenized PropagationSecurity: One of the six STACCR™ pillars. The mechanism by which context moves across system boundaries: raw sensitive data is replaced with scoped, revocable token references before propagation. Downstream systems receive only what they are authorized to see, and tokens can be individually revoked without touching the source data. Provides the 'T' in STACCR™.
ZT-IAM(Zero Trust Identity & Access Management)Core: The four-layer infrastructure stack that CCL sits above. Layers 1–4 cover zero-trust controls at the network (L1), device (L2), workload/service (L3), and application/API (L4) levels. While ZT-IAM controls who can access what, it does not govern context — the meaning, provenance, consent status, and audit trail of the data that flows through authenticated and authorized sessions. CCL's Layer 5 fills that gap.

25 of 25 terms