CCL Glossary

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, Ed25519-signed record of the decision is written.

Note: This describes how a request flows at runtime. It is a complementary view to the 4-Tier Deployment Topology, which describes where components physically sit.

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.

Note: Distinct from the 4-Layer Governance Pipeline, which describes the runtime request lifecycle rather than physical placement.

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.

Note: The deck's Architecture section highlights four of these for positioning purposes (Layer 5, Tokenization-First, Identity-Agnostic, No Cross-Tenant Aggregation). The deck's four and the whitepaper's six are complementary framings of the same invariants, not competing counts.

Auditable ProvenanceSecurity

One of the six STACCR™ pillars. Every governance decision is recorded as an immutable, Ed25519-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. An AES-256-GCM-encrypted container designed for Ed25519-over-JCS-canonicalized-JSON signing 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.

Note: The envelope carries token references to data, never raw sensitive data itself — a consequence of the Tokenization-First invariant.

Cryptographic Erasure(CE)Security

CCL's mechanism for cryptographically enforced Right to Erasure. Rather than hunting down and deleting copies of data, CCL destroys the per-subject User Encryption Key (UEK) held in the dedicated erasure-key store. The tenant Key Encryption Key (KEK) remains in the customer's cloud KMS, where it is rotated but never destroyed. The UEK wraps every Data Encryption Key (DEK) version ever issued for that subject — destroying it makes all DEK versions permanently unwrappable by construction, rendering all ciphertext inaccessible across every adapter, backup, and replica. Erasure is guaranteed by cryptography, not by policy.

Note: Implemented via CE Adapter Contracts that coordinate UEK lifecycle and adapter confirmation across participating systems.

DEK(Data Encryption Key)Security

A per-context AES-256-GCM symmetric key used to encrypt a subject's context payload. DEKs exist only as wrapped blobs — each is encrypted (wrapped) under the per-subject User Encryption Key (UEK) held in the dedicated erasure-key store. The tenant Key Encryption Key (KEK) remains in the customer's cloud KMS and is rotated, never destroyed. When a user exercises their Right to Erasure, CCL destroys the UEK via a Key Destruction Workflow in the dedicated erasure-key store; this makes every historical DEK version permanently unwrappable by construction, rendering all ciphertext 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.

Note: No existing protocol, IdP, or platform currently fills Layer 5, which is what makes CCL a net-new infrastructure category rather than a feature of an existing product.

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 Ed25519 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