SecureToolKit is a language-independent authorization protocol. Swift is not the protocol. The Swift package is the reference implementation of the protocol baseline described by this document.
The Phase 1–6 architecture is frozen at the baseline designated
RC0_FINAL_1. The reference implementation provides the structural registry,
schema-validation, canonical-request, authenticated-input, deterministic-policy,
authorization-issuance, and authorization-validation behavior for that
baseline.
The architecture has received an architectural GO. This status is not a production-readiness or deployment approval. The production profile remains incomplete because the baseline does not provide cryptographic authenticity, trusted time, revocation, durable replay prevention, atomic consumption storage, audit persistence, or executor binding.
This document completely specifies the accepted Phase 1–6 protocol semantics. It does not specify later phases, a production deployment profile, or an implementation of any deferred production facility. Phase 7 has not begun, and this document defines no confirmation collection or approval behavior.
- 1. Status
- 2. Normative language
- 3. Protocol scope
- 4. Protocol terminology
- 5. Trust domains
- 6. High-level protocol pipeline
- 7. Protocol principles
- 8. Authority monotonicity
- 9. Registry and tool identity
- 10. Closed schema and typed request meaning
- 11. Canonical Request semantics
- 12. Proposal Assessment continuity
- 13. Host Capability Boundary
- 14. Host Authority and Role Authority
- 15. Intent and Security Context binding
- 16. Provenance and Influence binding
- 17. Evaluation Input construction
- 18. Slice 2 security properties
- 19. Policy Snapshot and administration
- 20. Policy rule model
- 21. Policy evaluation semantics
- 22. Policy Decision continuity
- 23. Authorization issuance eligibility
- 24. Authorization scope derivation
- 25. Authorization identity and content
- 26. Authorization lifetime and freshness
- 27. Obligation handling
- 28. Replay identity and Consumption Binding
- 29. Authorization Validation Context
- 30. Authorization validation semantics
- 31. Issuance-to-validation consistency
- 32. Validation result and authority status
- 33. Slice 3 failure model
- 34. Slice 3 security properties
- 35. Protocol-level security invariants
- 36. Protocol state machine
- 37. Complete failure model
- 38. Privacy and data-minimization model
- 39. Deterministic limits
- 40. Threat coverage
- 41. Deferred production facilities
- 42. Future-phase compatibility
- 43. Conformance model
- 44. Swift reference-implementation mapping
- 45. Review and evidence history
- 46. Protocol status summary
- 47. Canonicalization Version 1 Octet Format
- 48. Closed Protocol Vocabularies
- 49. Identifier and Name Grammars
- 50. Deterministic Ordering Rules
- 51. Normative Canonicalization-v1 Test Vectors
| Concept group | Defining section |
|---|---|
| Model, Proposal, Host, and controlled artifact | Section 4 |
| Registry, Registry Snapshot, Tool Identifier, Tool Version, Tool Definition, and Schema | Sections 4 and 9 |
| Proposal Assessment and Canonical Request | Sections 4, 11, and 12 |
| Host authority domain, Host Capability Boundary, Host Authority, and Role Authority | Sections 4 and 13–14 |
| Security Context, Intent, Provenance, Influence, and Evaluation Input | Sections 4 and 15–17 |
| Policy Definition, Policy Rule, Policy Snapshot, Policy Decision, and Obligation | Sections 4 and 19–22 |
| Authorization, Lifetime, Freshness, and explicit time | Sections 4 and 23–27 |
| Replay Identity, Consumption Identity, Authorization Consumption Binding, and Consumption | Sections 4 and 28 |
| Authorization Validation Context, Validation, and Validation Result | Sections 4 and 29–32 |
| Capability and Resource | Sections 4, 8, and 24 |
| Executor and Execution | Sections 4, 6.10, and 36 |
| Rule | Normative location |
|---|---|
| Model has no authority | Sections 5.2 and 7.8 |
| Proposal is not Intent | Sections 4 and 15 |
| Authority monotonicity | Sections 7.4 and 8 |
| Capability intersection | Sections 8 and 24 |
| Resource intersection | Sections 8 and 24 |
| Empty Resource semantics | Sections 8 and 24 |
| Canonical Request equality limits | Sections 7.11 and 11 |
| Policy precedence | Section 21 |
| Allow is not Authorization | Sections 7.1 and 23 |
| Issuance eligibility | Section 23 |
issuedAt and freshness |
Sections 26 and 31 |
| Validation independence | Sections 29 and 30 |
| Replay Identity | Section 28 |
| Validation versus Consumption | Sections 7.3 and 32 |
| Consumption before Execution | Sections 6.9, 32, and 36 |
| Production NO-GO | Sections 41 and 46 |
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in all capitals.
MUST expresses an absolute protocol requirement. MUST NOT expresses an
absolute protocol prohibition. SHOULD and SHOULD NOT
express requirements for which an implementation can have a valid reason to
deviate only after understanding and accepting the security consequences. MAY
expresses an optional protocol behavior.
This document completely specifies the accepted Phase 1–6 protocol semantics, including:
- the trust relationship between model proposals, host-controlled evidence, controlled protocol artifacts, and external execution;
- exact, version-bound registry resolution and closed schema validation;
- deterministic construction of a canonical request from validated input;
- binding of a canonical request to authenticated host context, intent, provenance, influence, freshness, and authority ceilings;
- deterministic evaluation of an explicit immutable policy snapshot;
- controlled authorization issuance with exact bindings, intersection-only scope, explicit freshness, and finite lifetime;
- deterministic structural validation against independently supplied host expectations; and
- the requirement for host-controlled atomic single-use consumption before any protected side effect.
The Phase 1–6 protocol does not specify later phases, a production deployment profile, or implementations of these deferred facilities:
- tool execution or an executor implementation;
- cryptographic algorithms, keys, signatures, message authentication, or trust stores;
- serialization or a portable authorization-artifact format;
- persistence, replay storage, atomic-consumption storage, or revocation infrastructure;
- networking or external-system transport;
- audit-event production, audit storage, anchoring, or recovery;
- deployment topology, operational configuration, or a production profile;
- authentication-provider, trusted-clock, or host-application implementation;
- user interfaces or confirmation presentation and collection; or
- model invocation, planning, memory, tool routing, retries, or agent behavior.
An implementation MUST NOT infer that an omitted facility exists. If a required security facility is unavailable, processing MUST fail closed rather than use a weaker substitute.
Model: An inference component that can produce a Proposal. A Model and all of its output are untrusted and carry no authority.
Proposal: A model-controlled request naming a tool version and supplying host-parsed structured arguments. A Proposal is input to validation, not a decision, intent statement, or grant.
Host: The application-controlled security domain that authenticates users, establishes authority and evidence, provisions registries and policies, supplies explicit time, performs required consumption, and owns execution.
Controlled artifact: An immutable protocol value produced only by its defined validation, evaluation, or issuance transition. Restricted construction provides in-process structural provenance, not cryptographic authenticity, portability, or authority beyond the artifact's stated role.
Registry: An immutable, versioned collection that resolves an exact tool identity and version to one Tool Definition. Missing, ambiguous, stale, or retired resolution is not authority.
Registry Snapshot: One immutable identified generation of Registry content, including its complete deterministically ordered Tool Definitions. See Section 9.
Tool Identifier: The exact registered lowercase-ASCII namespace identity of a tool family. It is always used with an exact Tool Version. See Sections 9 and 49.
Tool Version: A positive unsigned 64-bit generation selecting one exact Tool Definition for a Tool Identifier. It is not a compatibility range or latest version. See Sections 9 and 49.
Tool Definition: An immutable registered declaration of one exact tool version, including its complete Schema, lifecycle, maximum capabilities, and reviewed metadata. It contains no executable behavior and grants no authority.
Schema: A closed, versioned, bounded description of accepted structured arguments and their exact types, including reviewed Resource-bearing fields. Unknown fields, types, versions, and ambiguous values are invalid.
Proposal Assessment: Privacy-minimized controlled Host evidence binding one raw Proposal identity to an independent assessment identity, expected lineage collection identities, and one Host authority domain. See Section 12.
Canonical Request: The controlled result of complete schema validation. It binds the exact registry and tool definition, schema, canonicalization version, validated arguments, argument-derived Resources, and proposal assessment.
Evaluation Input: A complete immutable binding of one Canonical Request to Host Authority, Security Context, Intent, requested scope, Provenance, Influence, explicit evaluation time, and renewal state. It is not a policy outcome or authorization.
Policy Definition: One immutable identified and versioned host-administered policy containing its complete ordered Policy Rules, lifecycle, and publication binding. See Sections 19–20.
Policy Rule: One immutable uniquely identified bounded condition, effect, scope constraint, reason, and set of Obligations within a Policy Definition. See Section 20.
Policy Snapshot: An immutable, explicitly selected, versioned collection of complete Policy Definitions. It is an evaluation input and is not ambient or inferred configuration.
Policy Decision: The deterministic evidence produced by evaluating one exact Evaluation Input against one exact Policy Snapshot. Its outcome is deny, require confirmation, or allow. An allow outcome is not Authorization.
Obligation: An inert closed structured requirement retained through Policy Rule, Policy Decision, issuance, and Validation continuity. It grants no authority and invokes no behavior. See Section 27.
Authorization: Controlled immutable structural evidence that an eligible Policy Decision permitted issuance for one exact subject, request, scope, policy, host domain, freshness state, lifetime, and future consumption identity. It is not execution and is not cryptographically authentic in this baseline.
Authorization Validation Context: The Host-controlled independent expectation set against which one Authorization is structurally validated. It is not derived from the artifact under Validation. See Section 29.
Validation: A pure deterministic comparison of Authorization against independently supplied Host expectations and explicit validation time. Successful Validation produces structural evidence and a consumption requirement; it does not consume authority.
Validation Result: Controlled structural evidence that Validation either succeeded against all exact independent expectations or failed. Success is not Authorization, Consumption, replay prevention, or execution permission. See Section 32.
Consumption: A Host-controlled atomic single-use transition that records one Authorization as used before a protected side effect. Phase 1–6 requires this transition but does not implement it.
Executor: A Host-controlled component that performs a side effect only after the Host has completed all required validation and consumption. An Executor is outside the SecureToolKit trust boundary.
Replay Identity: A Host-supplied correlation identifier bound into Authorization. It is not randomness, uniqueness proof, replay prevention, or evidence of Consumption.
Consumption Identity: A Host-supplied correlation identifier naming the future Consumption attempt bound into Authorization. It is not a receipt, reservation, uniqueness proof, or evidence that Consumption occurred.
Authorization Consumption Binding: The complete logical structural value a future Host atomic facility compares and consumes, including the complete Authorization binding, scope, lifetime, replay and Consumption identities, and single-use contract. It is non-consuming evidence. See Section 28.
Host authority domain: One exact in-process Host security domain identified by a retained Host Capability Boundary. Descriptive equality cannot merge two domains.
Host Authority: A Host-established immutable ceiling on capabilities and exact resources within one Host authority domain. It can constrain protocol processing but cannot expand another authority source.
Role Authority: An attenuated Host Authority permitted to establish one declared class of host fact or administer policy. Role Authorities compose only within one Host authority domain and one exact entitlement ceiling; composition does not union authority.
Host Capability Boundary: An opaque Host-retained capability identifying one in-process Host authority domain. It binds controlled evidence and artifacts to that domain. Possession is privileged; it is not a secret, signature, cryptographic proof, or process-isolation mechanism.
Security Context: Controlled Host evidence binding an authenticated subject, tenant, session state, assurance classifications, authentication methods, optional delegation identity, and explicit validity. It contains no credentials or secrets.
Intent: Controlled Host evidence binding an authenticated subject to one exact request or one exact bounded tool definition, explicit capability and resource ceilings, validity, session state, and renewal generation. Model text does not establish Intent.
Provenance: Structured evidence describing the source, custody, transformations, and verification state of information. Missing, unknown, unverifiable, or model-asserted Provenance is untrusted.
Influence: Structured evidence identifying content, systems, or events that may have shaped a Proposal, including material absent from its final arguments. Completeness is local to an explicit collection boundary and is never inferred globally.
Explicit time: A bounded time value supplied as a direct Host input to a protocol transition. It is deterministic input data and is not proof of a trusted or rollback-resistant clock.
Freshness: The relationship among explicit evaluation time, issuance time, renewal state, validity intervals, and any bounded maximum evaluation age. It is host-supplied time data, not proof of trustworthy time.
Lifetime: The finite authorization interval with an inclusive issuance time, exclusive expiry, explicit maximum duration, and bounds inherited from the exact input. Issuance time MUST NOT precede bound evaluation time and MAY follow it only within every applicable freshness obligation.
Capability: A closed privilege or protected-effect category. Effective Capabilities are obtained only by intersection of every required authority ceiling; unknown or excess capabilities are invalid.
Resource: An exact protected-resource identifier originating only from reviewed typed canonical arguments. An empty Resource set means no resource authority and never means all resources, missing scope, or wildcard scope.
The Host is trusted only for the roles and assumptions explicitly assigned to it. It establishes authenticated facts, protects the Host Capability Boundary, supplies registry and policy administration, and owns consumption and execution. A compromised or dishonest Host is outside the protocol guarantee.
The Model, its Proposal, semantic classifications, explanations, claimed urgency, and claimed approval are untrusted. Model-controlled data MAY cause denial or escalation. It MUST NOT independently cause authorization.
Controlled protocol artifacts arise only through their defined validation, evaluation, or issuance transitions. Restricted construction provides structural provenance within one process; it does not provide cryptographic authenticity, portability, or protection from a compromised Host.
Host-controlled evidence represents authenticated context, intent, provenance, influence completeness, authority, and explicit time supplied through restricted Host paths. Raw claims are not trusted merely because they are structured. Evidence MUST satisfy exact role, domain, scope, value, and freshness bindings before it contributes to a controlled artifact.
Model-controlled input includes tool identity candidates, arguments, provenance claims, influence declarations, and any free text associated with a Proposal. It MUST be treated as untrusted input and MUST NOT be promoted into Host evidence through inference or convenience construction.
The execution environment is Host-controlled and outside the SecureToolKit trust boundary. Before a protected side effect, the Host execution environment MUST match the validated request, enforce required preconditions, and atomically consume authority. The Host then owns the side effect. Phase 1–6 defines no Executor implementation.
External identity providers, storage, clocks, policy distribution, tools, networks, and protected resources are outside the protocol core. Their outputs are not trusted unless the Host converts them into exact evidence through an applicable trusted integration. Registration or trusted transport alone MUST NOT upgrade arbitrary content.
Model Proposal
|
v
Registry
|
v
Schema Validation
|
v
Canonical Request
|
v
Evaluation Input
|
v
Policy
|
v
Authorization
|
v
Validation
|
v
Host Consumption
|
v
Execution
Purpose: represent a requested tool action as untrusted structured input. Authority: the Model has no protocol authority and the Proposal grants none. Failure behavior: malformed, unsupported, or unresolvable proposal content MUST be rejected and MUST NOT be repaired into another identity or value.
Purpose: resolve an exact tool identity and version to one immutable Tool Definition. Authority: Registry content is Host-administered configuration and defines ceilings, not grants. Failure behavior: missing, ambiguous, stale, or retired resolution MUST fail closed without fallback to another version.
Purpose: validate every structured argument against the complete exact Schema. Authority: validation can reject input but cannot authorize it. Failure behavior: unknown, duplicate, missing, ambiguous, mistyped, unsupported, or excessive content MUST reject the whole request without partial output.
Purpose: preserve one deterministic, version-bound representation of the exact validated request and its argument-derived Resources. Authority: a Canonical Request is controlled request evidence, not permission. Failure behavior: if canonical construction or any exact definition, schema, or assessment binding fails, a Canonical Request MUST NOT be produced.
Purpose: bind the Canonical Request to exact Host Authority, Security Context, Intent, requested scope, Provenance, Influence, freshness, and renewal facts. Authority: only validated Host evidence can contribute authority ceilings; this stage produces no decision or grant. Failure behavior: any missing, stale, mixed-domain, mismatched, or excessive fact MUST reject complete input construction without a partial result.
Purpose: evaluate every applicable rule from one explicit Policy Snapshot over one exact Evaluation Input. Authority: policy can preserve or reduce prior ceilings; it cannot add authority, and an allow outcome remains non-authoritative decision evidence. Failure behavior: missing or unknown policy, indeterminate conditions, no eligible match, or scope excess MUST result in denial. Deny takes precedence over confirmation, which takes precedence over allow.
Purpose: issue controlled evidence for one eligible allow decision after exact binding, obligation, scope, freshness, and lifetime checks. Authority: effective scope MUST be the intersection of every required ceiling and MUST NOT be broadened during issuance. Failure behavior: deny or confirmation outcomes, unsupported obligations, mismatched bindings, invalid scope, or invalid lifetime MUST prevent issuance.
Purpose: compare Authorization with independent exact Host expectations and explicit validation time. Authority: successful Validation confirms structural agreement only; it grants no execution capability and performs no Consumption. Failure behavior: any identity, request, policy, scope, lifetime, freshness, replay, consumption, or Host-domain mismatch MUST invalidate the artifact.
Purpose: enforce the single-use requirement before a protected side effect. Authority: Consumption is a Host operation over the complete logical authorization binding and is not implemented by Phase 1–6. Failure behavior: a missing, repeated, failed, or indeterminate Consumption MUST prevent Execution.
Purpose: perform the Host-owned side effect represented by the exact authorized request. Authority: only the Host execution environment can execute, after its required verification and atomic Consumption succeed. Failure behavior: absent, invalid, expired, mismatched, or unconsumed Authorization MUST result in no protected side effect.
Authorization is controlled structural evidence for one exact action. A policy allow, Proposal, canonical request, validation result, or correlation identifier is not a substitute for Authorization.
SecureToolKit MUST NOT invoke tools or accept executable behavior into its core authorization path. Execution remains exclusively Host-owned.
Validation is pure and repeatable. Repeated successful Validation does not reserve, mutate, or consume authority and MUST NOT be treated as replay prevention.
Every stage MUST preserve or narrow prior authority ceilings. Capabilities and Resources MUST be intersected, never unioned or inferred into existence.
Missing, unknown, unverifiable, indeterminate, or model-asserted security state MUST NOT be treated as trusted or permissive state.
Missing policy, unsupported versions, ambiguous content, failed exact binding, or unavailable required security facilities MUST deny or invalidate processing. No stage MAY silently select a weaker path.
Critical validation, policy, issuance, and validation transitions MUST be deterministic over complete explicit versioned inputs. They MUST NOT depend on ambient network state, locale, randomness, unordered iteration, hidden global state, or an unbound clock.
7.8 No hidden authority
Authority-bearing inputs and expectations MUST be explicit. Model output, display metadata, descriptive text, process-global configuration, and semantic judgment MUST NOT act as hidden authority sources.
No capability or resource MAY appear in effective authorization unless it is present in every required exact ceiling. Empty scope means no authority, never unrestricted authority.
Time, policy, registry state, identity, intent, provenance, influence, and Host authority MUST be supplied and bound explicitly. Transport, registration, or process location alone MUST NOT establish trust.
Security-relevant identity and content MUST be compared as complete exact state at each applicable transition. Identifier equality, observationally equivalent outcomes, and canonicalization version 1 bytes alone are insufficient evidence of complete protocol equality.
Authority MUST remain equal or decrease as protocol processing advances. No transition MAY create authority absent from an applicable prior ceiling.
The effective capability scope is:
tool-definition maximum
INTERSECTION authenticated Host authority
INTERSECTION authenticated Intent ceiling
INTERSECTION explicitly requested capabilities
INTERSECTION later policy-constrained capabilities
The effective Resource scope is:
canonical argument-derived Resources
INTERSECTION authenticated Host authority
INTERSECTION authenticated Intent ceiling
INTERSECTION explicitly requested Resources
INTERSECTION later policy-constrained Resources
The policy terms above denote only later narrowing inputs. This section does not specify policy evaluation. Neither these equations nor Evaluation Input construction constitutes Authorization.
Scope composition MUST use intersection, not union or additive composition. It MUST NOT infer authority, expand wildcards, treat missing state as unrestricted, or supply default Capabilities or Resources. Empty means exactly no authority. An unknown or absent required ceiling MUST NOT broaden another ceiling. Every resulting Capability and Resource MUST occur in every required applicable ceiling.
A ceiling is an immutable upper bound supplied by an authority source. A request is the explicit subset sought for one Evaluation Input. An effective scope is the intersection of all applicable ceilings and the request. An authorization grant is later controlled evidence whose issuance is outside this slice. A ceiling, request, intersection, or Evaluation Input is not a grant.
Informally, Registry resolution selects an existing maximum and cannot add to it. Schema validation rejects invalid meaning and derives Resources only from reviewed fields. Canonical construction preserves that validated meaning. Host-evidence validation supplies finite ceilings, and Intent plus explicit requested scope can only select subsets. Evaluation Input construction rejects any excess or mismatch. Each Phase 1–4 transition therefore rejects, preserves, or narrows candidate authority; none can manufacture a new member.
A Tool Identifier MUST use the exact registered lowercase-ASCII namespace syntax: two through eight dot-separated segments, each one through 32 bytes, with a total maximum of 128 bytes. Segments contain lowercase letters, digits, and interior hyphens and begin and end with an alphanumeric byte. An implementation MUST NOT trim, fold case, normalize, repair, alias, or accept a lookalike as the same identifier.
A Tool Version MUST be an exact positive unsigned 64-bit generation. Lookup MUST require both Tool Identifier and Tool Version. It MUST NOT select a “latest” version, infer compatibility, fall back to another version, or perform name-only resolution.
A Registry Snapshot has one exact identity and positive generation and contains deterministically ordered immutable Tool Definitions. A later Snapshot, even with observationally similar content, is not automatically the same Snapshot. Snapshot-bound processing MUST retain the exact selected Snapshot identity and generation.
A Tool Definition binds its independent definition identity, exact Tool Identifier and Version, lifecycle, complete Schema identity and content, reviewed maximum Capabilities, and reviewed metadata. Identifier equality is insufficient when complete bound definition or Schema content differs. A Tool Definition MUST NOT contain an endpoint, callback, command, executable closure, or other execution behavior.
Resource-bearing fields are part of reviewed Schema content. Registry administration is a trusted Host responsibility and MUST be restricted to an authorized configuration path. Registry presence does not authorize use. Definition Capabilities are maxima, not grants. An eligible lifecycle is required for ordinary resolution but is insufficient for permission.
Resolution MUST fail closed for an unknown Tool Identifier, unknown Tool Version, retired or otherwise ineligible lifecycle, Snapshot mismatch, definition substitution, Schema substitution, ambiguous resolution, or any Registry or Schema limit violation. It MUST return neither a fallback definition nor a partial Snapshot.
Sections 48–50 provide the normative closed vocabularies, identifier grammars, and deterministic ordering rules used by this section.
The Schema is a finite, closed, versioned tree rooted at an object. Each object has an exact field set. Every field is explicitly required or optional; optional absence supplies no default. Additional properties, nullable fields, maps, references, cycles, unions, polymorphism, floating point, and implicit conversions are outside the version 1 Schema model.
The accepted value kinds are printable-ASCII string, reviewed Resource identifier, Boolean, signed 64-bit integer, unsigned 64-bit integer, closed enumeration, ordered array, and closed object. Null is always rejected. Value kinds MUST match exactly. Validation MUST NOT coerce, widen, parse a string as a number, render a number as a string, or convert between signed and unsigned integer domains.
Object input MUST preserve field occurrences until validation. Duplicate object fields, unknown fields, and missing required fields MUST reject. Schema fields are processed in exact deterministic name order, independent of object input order. Arrays preserve order, permit duplicate elements, and are not sorted. Enumeration values MUST be exact declared members with no aliases, case folding, or whitespace repair.
String values are empty or exact printable ASCII bytes 0x20 through 0x7E,
up to 1,024 bytes. Spaces, including leading and trailing spaces, are preserved.
Non-ASCII text, controls, embedded null, and normalization-dependent forms are
invalid. Field and enumeration names use exact restricted lowercase ASCII and
are at most 64 bytes.
Validation enforces at most 64 object fields, 64 enumeration cases, 64 array elements, nesting depth eight including the root, 256 Schema nodes, and 65,536 canonical bytes. Bounds are deterministic and inputs MUST NOT be truncated. Validation is all-or-nothing; a partial Canonical Request MUST NOT result.
Only a field explicitly reviewed and declared Resource-bearing can produce a protocol Resource. Arbitrary strings MUST NOT become Resources. Resource values originate from validated canonical arguments, use restricted exact identifiers, and are collected into deterministic unique order. Empty derivation means no Resource authority; it MUST NOT mean wildcard, omitted scope, or unrestricted access.
Duplicate Resource-bearing object fields reject as duplicate fields. Duplicate elements in an ordered array remain valid ordered argument data under the accepted Schema rules; Resource-set derivation does not turn repetition into additional authority. Ambiguous types or identities fail closed.
Sections 48–50 enumerate the closed value vocabulary, exact name grammars, and ordering rules used by Schema validation.
A Canonical Request binds:
- the exact Registry Snapshot identity and generation;
- the exact Tool Identifier, Tool Version, and complete Tool Definition;
- the exact complete Schema identity and content;
- the canonicalization version;
- the complete validated typed argument structure;
- deterministic canonical bytes;
- exact argument-derived Resources; and
- exact Proposal Assessment continuity.
A Canonical Request is controlled request evidence. It carries no Host permission, policy outcome, Authorization, or executable behavior. Construction MUST be all-or-nothing.
Canonicalization version 1 represents values with explicit type tags and length-delimited content. Multi-byte lengths and integers use network byte order. Signed integers use their 64-bit two's-complement bit pattern; unsigned integers use their 64-bit magnitude. Arrays preserve significant order. Object fields use deterministic Schema order. The representation has no locale, Unicode-normalization, semantic-normalization, or dynamic-extension dependency. This document does not add to or redefine that byte format.
The complete frozen octet grammar and normative vectors are specified in Sections 47 and 51.
Canonicalization-v1 byte equality does not imply complete Canonical Request structural equality.
Version 1 bytes do not alone commit to all complete Tool Definition content, all complete Schema content, Proposal Assessment, Host Authority, Intent, Security Context, Provenance, Influence, policy, freshness, lifetime, replay state, or Authorization. Complete request comparison includes controlled state outside those bytes, including Proposal Assessment and complete bound definition/Schema values. A later protocol artifact MUST NOT treat version 1 bytes alone as complete protocol equality.
Proposal Assessment is privacy-minimized controlled Host evidence connecting one raw Proposal to later request and lineage construction. It distinguishes:
- the raw Proposal identity selected by the untrusted request;
- an independent controlled Proposal Assessment identity;
- the exact expected Provenance record identities;
- the exact expected Influence collection identities; and
- the exact Host authority domain that produced the assessment.
Raw Proposal identity alone is insufficient. Raw model-declared Provenance and Influence remain untrusted. The Host creates controlled assessment evidence through a restricted Host path and MUST use correlation identifiers that contain no raw prompt, document content, raw argument values, credential, or secret.
One Canonical Request MUST retain the exact assessment for the same Proposal. Request content associated with proposal A MUST NOT compose with assessment or lineage evidence for proposal B. Provenance identities and Influence collection identities MUST equal the expected collections. Missing, changed, cross-domain, or substituted assessment continuity MUST fail closed.
Identifier equality does not replace complete expected-state comparison where the protocol binds additional content. Proposal Assessment is outside canonicalization-v1 bytes but remains part of complete Canonical Request structural equality.
The Host Capability Boundary is an opaque process-local capability identifying exactly one Host authority domain. Trusted Host code creates and retains it. Possession is privileged, and untrusted or model-controlled paths MUST NOT be able to reconstruct or recover an equivalent boundary from public artifact content or descriptive metadata.
Boundary equality is exact private-domain identity. Independently created boundaries are not equivalent even when supplied with identical descriptive inputs. Controlled Host evidence and every composing Role Authority MUST remain within the same exact boundary domain.
The boundary is not a credential, secret, signature, hardware root, IPC boundary, cryptographic attestation, or process-isolation mechanism. A compromised same-process Host is outside the protocol guarantee.
The Host MUST retain the active boundary for as long as dependent controlled artifacts can be constructed or checked. Loss, replacement, or recreation of a boundary MUST NOT silently establish an equivalent authority domain. Operations requiring the original domain MUST fail when that exact boundary is unavailable.
Host Authority is an immutable entitlement ceiling containing one exact Host authority domain, a finite nonempty Capability set, a finite exact Resource set, and declared roles. It constrains protocol processing but does not itself authorize. Empty Resources mean no Resource authority. A Resource-free Host Authority cannot support a Resource-bearing request.
Subject, tenant, session, delegation, validity, and renewal constraints are carried by the controlled Host evidence to which an authority applies. They MUST match exactly where present and MUST NOT be inferred as implicit expansion of the entitlement ceiling.
Authority values from different Host domains MUST NOT compose. Where multiple Role Authorities contribute to one input, they MUST share one exact entitlement ceiling. Their capabilities and Resources MUST NOT be unioned.
A Role Authority is an attenuation within one Host Capability Boundary. Each role can establish only its declared class of controlled Host fact. Possession of one role MUST NOT imply another role, mint a broader boundary, or broaden the shared ceiling. Authentication, Intent capture, Provenance verification, Influence collection, delegation, and policy administration are distinct roles. Policy administration is named here only as a separate authority role; this slice does not specify policy behavior.
A monolithic trusted-Host profile MAY intentionally retain all required roles. That is an explicit Host topology choice, not a protocol default or implicit composition rule.
Mixed boundaries, mismatched entitlement ceilings, unauthorized or missing roles, scope expansion, role substitution, duplicate conflicting role issuers, and expired or stale Host evidence MUST fail closed. These structural checks do not claim process isolation.
Authenticated Intent binds an exact subject, tenant where applicable, exact session or explicit session independence, optional delegation identity, one exact Canonical Request or one exact bounded Tool Definition, explicit Capability and Resource ceilings, a validity interval, and a positive renewal generation. It MUST NOT be derived authoritatively from model text, semantic prompt matching, or descriptive display text.
A bounded-tool Intent applies only to its exact Snapshot-bound Tool Definition; it is not unrestricted Intent. A request-bound Intent MUST NOT be reused for a different Canonical Request. Intent ceilings can narrow but MUST NOT enlarge the Tool Definition maximum, Host Authority, or requested scope.
Security Context binds subject, tenant, session state, authentication-method classifications, assurance classification, optional delegation identity, explicit validity, and matching controlled Host evidence. It contains no credential or secret. Assurance values are unordered classifications unless a later accepted policy explicitly interprets them; matching labels or display strings do not establish identity continuity.
Host Authority, Intent, Security Context, Canonical Request, Proposal Assessment, and Evaluation Input MUST preserve exact compatible identity, domain, target, and scope. Subject, tenant, session, delegation, validity, renewal, request, or Tool Definition mismatch MUST fail closed. This section defines no confirmation behavior.
Provenance records source identity, privacy-safe custody evidence, ordered transformation history, verification state, and exact membership in the expected record collection for one Proposal Assessment. Custody is represented only by the exact controlled evidence and transformations recorded for that source; it MUST NOT be inferred from a label. Provenance contains no raw content. Missing coverage defaults to unknown; known but unverified and model-asserted records remain untrusted.
A host-verified classification means only that exact controlled Host evidence matched the record and permitted transformation lineage. It is not a global truth, content-safety, or authority claim. Transformations remain ordered and visible where required. Unsupported semantic transformations MUST NOT receive a trust upgrade.
Influence records bounded nodes representing content, systems, tools, or events that may have shaped a Proposal, together with directed parent relationships and one explicit collection boundary. The structure MUST be deterministic and acyclic. Duplicate or missing node identities, invalid parent relationships, cross-boundary edges, cycles, and limit excess reject.
Completeness is exact per collection boundary:
- unknown provides no reliable coverage statement;
- partial states that some known Influences are represented; and
- complete requires exact controlled collector evidence for every Influence visible within that boundary.
No boundary implies global completeness. Missing material within a claimed complete boundary makes the claim inconsistent and MUST reject. Material outside the boundary remains a residual Host-collection risk rather than being silently classified complete.
Provenance and Influence collections MUST bind to the same exact Proposal Assessment, Host authority domain, subject, tenant, and session scope used for Evaluation Input. Collection substitution, missing expected identities, inconsistent completeness, or mixed domains MUST fail closed. Controlled lineage can constrain later processing but grants no authority. This section specifies no audit storage.
Evaluation Input is the complete immutable authority-bearing input to later policy evaluation. “Authority-bearing” means that it carries authenticated ceilings and request facts; it is not a Policy Decision, Authorization, or execution permission.
Evaluation Input binds the exact:
- Canonical Request and Proposal Assessment continuity;
- Registry Snapshot, Tool Definition, and Schema identity and complete content;
- authenticated Host Authority and applicable Role Authorities;
- Security Context and Intent;
- explicitly requested Capabilities and Resources;
- equality of requested Resources and canonical argument-derived Resources;
- Provenance records and coverage;
- Influence graph, collections, and boundary-local completeness;
- explicit evaluation time and all applicable validity intervals;
- Intent renewal generation; and
- Host authority domain.
Construction MUST occur only through the controlled complete-input transition. All inputs MUST belong to the same exact Host authority domain and preserve complete exact continuity. Requested scope MUST NOT exceed the Tool Definition, Host Authority, or Intent ceilings. Required freshness and validity MUST be rechecked at construction against explicit evaluation time.
Construction MUST be deterministic and enforce all collection and complexity limits before unbounded work. It MUST NOT read ambient policy, repair semantic mismatches, return a partial input, issue Authorization, or grant execution permission. Unknown, absent, stale, excessive, or mismatched required evidence MUST reject.
| Input fact | Authority source | Required exact binding | Failure result |
|---|---|---|---|
| Canonical Request | Registry and Schema validation | Snapshot, definition, Schema, assessment, arguments, Resources | Reject input construction |
| Proposal Assessment | Restricted Host assessment path | Proposal identity, expected lineage collections, Host domain | Reject assessment continuity |
| Host Authority | Authenticated Host bootstrap | Boundary domain and entitlement ceiling | Reject Host authority |
| Role evidence | Applicable Role Authorities | Role, issuer, common domain, common ceiling, exact fact | Reject attestation composition |
| Security Context | Authentication authority | Subject, tenant, session, delegation, validity | Reject identity or freshness binding |
| Intent | Intent-capture authority | Target, subject, tenant, session, ceilings, validity, renewal | Reject Intent binding |
| Requested Capabilities | Explicit Host request | Subset of definition, Host, and Intent ceilings | Reject Capability scope |
| Requested Resources | Explicit Host request | Exact canonical-derived set and subset of Host and Intent ceilings | Reject Resource scope |
| Provenance | Provenance authority where verified | Assessment, expected records, scope, transformations, Host domain | Reject lineage binding |
| Influence | Influence collector where complete | Assessment, graph, collections, completeness, scope, Host domain | Reject lineage binding |
| Evaluation time | Explicit Host input | Every applicable inclusive/exclusive validity boundary | Reject stale or future evidence |
| Renewal state | Intent-capture evidence and explicit expectation | Exact positive generation | Reject renewal binding |
Evaluation Input carries these authenticated ceilings and exact request facts into later policy evaluation. It remains neither a policy result nor a grant.
This table is a non-normative summary of requirements stated in Sections 9–17; it establishes no additional requirement.
| Property | Implemented core guarantee | Host integration obligation |
|---|---|---|
| Exact request identity | Bind and compare the complete controlled request state | Preserve and supply the intended exact request |
| Closed typed request meaning | Reject values outside the closed Schema and its limits | Preserve object-field occurrences and exact scalar domains when parsing |
| Canonical determinism | Produce the accepted deterministic version 1 representation | Supply the same validated typed meaning; do not substitute an external encoding |
| Proposal Assessment continuity | Bind the request and lineage expectations to one exact assessment | Create accurate privacy-safe assessment evidence through restricted paths |
| Same-domain Host authority | Reject mixed or substituted boundary domains | Protect and retain the genuine active boundary |
| Role attenuation | Restrict each role to its declared fact class and common ceiling | Distribute and invoke roles only through authenticated Host paths |
| Explicit authenticated Intent | Bind exact target, identity, scope, validity, and renewal state | Capture and attest actual user Intent outside model-controlled paths |
| Provenance and Influence binding | Enforce expected collections, scope, structure, and boundary-local completeness | Collect accurate privacy-safe lineage and declare collection boundaries honestly |
| Intersection-only scope | Reject scope outside any applicable ceiling | Supply explicit finite ceilings and requests without treating absence as unrestricted |
| Complete Evaluation Input | Construct only the complete exact input or reject | Supply all required controlled evidence and explicit evaluation time |
| No grant before later issuance | Expose no grant or execution permission from this slice | Never treat request, assessment, lineage, or Evaluation Input evidence as execution authority |
These properties establish exact bounded input for later processing. They do not specify policy evaluation, Authorization issuance or validation, replay storage, Consumption implementation, execution, confirmation, or deployment.
A Policy Snapshot is an immutable, explicitly selected, exactly versioned collection of complete policy content. It is bound to one exact Host authority domain and is created only through an authorized policy-administration role in that domain. Policy administration is authority to define bounded policy content; it is not authority to use or execute a tool.
A Policy Snapshot binds at least:
- its exact snapshot identity and positive generation;
- every complete Policy Definition in deterministic identity and version order;
- every exact rule identity, condition tree, effect, constraint, reason, and obligation;
- each policy lifecycle and applicability identity;
- the exact publishing Role Authority and Host authority domain; and
- all applicable per-policy and aggregate deterministic limits.
Initial publication uses generation one. A successor retains prior policy versions and their complete rule content, uses the same snapshot identity and exact next generation, and permits only accepted one-way lifecycle transitions. Old snapshots remain immutable. Retired policy versions remain inspectable but are ineligible for lookup and evaluation.
Policy selection MUST name the exact Snapshot identity and generation and the exact Policy identity and generation. It MUST NOT use an ambient singleton, mutable global configuration, deployment state, Model choice, or an inferred “current” or “latest” version. Identifier and version equality are insufficient when complete Snapshot or Policy Definition content differs. Observationally equivalent rule outcomes do not establish policy equality, and a later Snapshot with similar content is not automatically the same Snapshot.
Policy content can only preserve or reduce authority. It MUST NOT introduce a Capability or Resource absent from an applicable prior ceiling.
Publication or selection MUST fail closed for a missing or unknown Snapshot, wrong generation, missing or unknown Policy version, mixed Host domains, missing policy-administration role, Snapshot or content substitution, retired Policy, excessive size or complexity, unsupported structure, invalid lifecycle transition, or non-successor generation. Publication is all-or-nothing. The core verifies the structural role and domain binding; authenticating and restricting the administrative caller remains a Host obligation.
The policy vocabulary is closed. A Policy Definition contains one or more immutable uniquely identified rules in deterministic identity order. Each rule contains one normalized bounded condition, one effect, one stable reason, an explicit Capability and Resource constraint for every non-deny effect, and a bounded set of inert obligations.
Conditions are limited to unordered all, unordered any, and the accepted
typed predicates below. Empty or duplicate compound children reject. Compound
children are normalized to deterministic order. Nesting is root-inclusive and
finite. Negation, priority, first-match control flow, callbacks, arbitrary field
paths, scripts, regular expressions, semantic Model judgment, network lookup,
ambient external state, and side effects are not supported. Evaluation MUST NOT
mutate either Evaluation Input or Policy Snapshot.
Each predicate produces matched, not matched, or indeterminate.
Within both all and any, any indeterminate child makes the compound
indeterminate. Otherwise all matches only when every child matches, and any
matches when at least one child matches. Any indeterminate condition anywhere
in the selected Policy causes global denial.
The accepted condition families are:
| Condition family | Exact Evaluation Input fact and comparison | Indeterminate case | Operand and limit rule |
|---|---|---|---|
| Tool identity | Exact Tool Identifier, Tool Version, or Tool Definition identity equality | None | Exact typed value |
| Registry identity | Exact Registry Snapshot identity and generation equality | None | Exact typed pair |
| Tool classification | Exact lifecycle, risk, side-effect, or reversibility classification equality | None | Closed classification |
| Subject and tenant | Exact subject or tenant equality | None | Exact typed identity |
| Session | Exact session equality, or exact session-independent state | Exact-session comparison when the input is session-independent | Closed session state |
| Delegation | Presence test or exact delegation identity equality | Exact-identity comparison when delegation is absent | Exact optional identity |
| Assurance | Exact membership of the input's one assurance classification in an accepted set | None | Nonempty and unique; the Swift reference implementation admits at most 6 closed classifications |
| Authentication methods | Exact method membership or inclusion of every required method | None | Nonempty and unique; the Swift reference implementation admits at most 6 closed methods per predicate operand |
| Requested Capabilities | Requested set is a subset of the operand, or includes every operand member | None | Nonempty, unique, at most 16 Capabilities |
| Intended Capabilities | Intent ceiling includes every operand member | None | Nonempty, unique, at most 16 Capabilities |
| Requested Resources | Requested set equals one exact singleton Resource, is a subset of the operand, or includes every operand member | None | Multi-value operand is nonempty, unique, and at most 32 exact Resources |
| Provenance coverage | Exact unknown or represented coverage equality | None | Closed coverage classification |
| Provenance source | At least one record has the exact source classification | Coverage is not represented | Closed source classification |
| Provenance trust | Every represented record has a trust classification in the accepted set | Coverage is not represented or the represented record set is empty | Nonempty and unique; the Swift reference implementation admits at most 3 closed trust classifications |
| Provenance transformation | At least one record contains the exact transformation | Coverage is not represented | Closed transformation classification |
| Absence of semantic transformation | Every represented record lacks a transformation that prevents trust upgrade | Coverage is not represented | No operand |
| Influence boundary completeness | Exact completeness for one exact collection boundary | The boundary is absent | Exact boundary and closed completeness classification |
| All Influence boundaries complete | Every declared collection is complete | No Influence collection exists | No operand; never implies global completeness |
| Influence kind presence | At least one Influence record has the exact kind | None | Closed kind classification |
| Influence kind absence | No Influence record has the exact kind | No Influence collection exists | Closed kind classification |
| Influence boundary presence | The exact collection boundary exists | None | Exact boundary identity |
| Maximum Influence count | Record count is no greater than the operand | None | Integer from 0 through 64 |
| Evaluation validity | Evaluation time is at or after the exact not-before boundary and before the exact expiry | None | One valid explicit interval |
| Renewal generation | Exact positive renewal-generation equality | None | Exact typed generation |
| Maximum Intent age | Evaluation time minus Intent issue time is no greater than the operand | Evaluation precedes Intent issue time | Inclusive age; the Swift reference implementation uses an unsigned 64-bit operand |
| Maximum Security Context age | Evaluation time minus Security Context issue time is no greater than the operand | Evaluation precedes Context issue time | Inclusive age; the Swift reference implementation uses an unsigned 64-bit operand |
A false comparison is not matched. An indeterminate comparison is never treated as false for the purpose of recovering an allow path; it causes global denial. Invalid predicate operands, empty collection operands, duplicates, unsupported condition forms, or exceeded limits reject publication before evaluation.
Section 48 enumerates every closed predicate, effect, obligation, and stable reason token. Section 50 defines their deterministic ordering.
The accepted structural limits are 32 Policies per Snapshot, 128 rules per Policy, 512 rules per Snapshot, 8,192 condition nodes per Snapshot, 64 nodes per rule, depth 8, 16 compound children, 8 obligations per rule, 128 unique obligations per Decision, 128 reasons, and 128 matched rule identities. Limits reject without truncation or partial publication.
Evaluation applies one exact Evaluation Input to one exact Policy Snapshot and one exactly selected Policy Definition within the same Host authority domain. The transition is pure and deterministic over those explicit values.
Every rule is evaluated. No matching rule can short-circuit evaluation, and no early success can hide a later deny or indeterminate condition. Resolution is:
- any indeterminate condition results in deny;
- otherwise, any matched deny rule results in deny;
- otherwise, any matched confirmation rule results in require confirmation;
- otherwise, an eligible matched allow rule results in allow; and
- otherwise, the result is deny.
The precedence is therefore:
deny > requireConfirmation > allow
Deny is terminal for Authorization eligibility. Require confirmation is not allow and is not satisfiable in Phase 1–6. Allow is necessary but insufficient for Authorization. A Policy Decision is deterministic controlled evidence, not permission to execute.
Every matched non-deny rule contributes an explicit Capability ceiling and Resource ceiling. Evaluation starts from the requested scope, intersects it with authenticated Host Authority, and filters it through every matched non-deny constraint. It MUST NOT union constraints or add a value. A non-deny outcome is eligible only when every exact requested Capability and Resource survives. Scope loss produces denial rather than an under-bound non-deny result.
Missing Policy, unknown Policy version, retired Policy, no eligible match, indeterminate evidence, scope loss, or exceeded Decision limits results in denial. A mixed Host domain, unsupported Evaluation Input version, or other structural evaluator misuse rejects the transition without an authoritative partial Decision. Both forms are fail-closed and make Authorization ineligible.
Decision reasons consist of the stable outcome reason plus the stable reasons from all matched rules. They are deduplicated and ordered by the closed protocol reason order. Matched rule identities are unique and sorted. Obligations from all matched rules are deduplicated and ordered by their closed deterministic obligation order. If a Decision aggregation limit is exceeded, the result is a deny Decision with the policy-limit reason, empty constrained scope, and no obligations.
The complete Policy Decision binds the exact Evaluation Input, complete Policy Snapshot and selected Policy Definition where present, exact outcome, constrained Capability and Resource scopes, reasons, matched rules, obligations, Decision identity and version, and Host authority domain.
Complete Policy Decision continuity includes:
- the exact Decision identity and representation version;
- the complete exact Evaluation Input;
- the complete exact Policy Snapshot and selected Policy Definition;
- requested Snapshot and Policy identities and generations;
- the exact outcome;
- exact constrained Capabilities and Resources;
- exact reasons, matched rule identities, and obligations; and
- the exact Host authority domain retained by the controlled values.
Outcome equality alone is insufficient. Allow outcomes from different Policy Snapshots are not interchangeable. Matching constrained scope with different reasons, matches, or obligations does not establish equality. Identifier and version equality does not replace complete content equality. An observationally similar recomputation does not permit substitution.
Controlled issuance MUST compare exact Decision content and independently re-evaluate the exact selected Policy against the exact Evaluation Input and Snapshot. Re-evaluation is defense in depth and does not relax the preceding structural equality requirement.
Before controlled issuance, a Policy Decision remains non-authoritative because it has not satisfied issuance eligibility, final exact scope recomputation, obligation handling, lifetime, replay, consumption, and artifact-construction requirements. Even an exact allow Decision is not Authorization.
Controlled issuance requires all of the following:
- one exact controlled Evaluation Input;
- one exact Policy Snapshot and selected complete Policy Definition;
- one exact controlled Policy Decision whose outcome is allow;
- one exact Host authority domain proven by the independently retained Host Capability Boundary;
- exact Proposal Assessment continuity through Canonical Request and Evaluation Input;
- exact Registry Snapshot, Tool Definition, Schema, canonicalization version, typed arguments, and argument-derived Resource continuity;
- exact subject, tenant, session, optional delegation, Intent, Security Context, validity, and renewal continuity;
- exact policy identity, generation, complete content, Decision, constrained scope, reasons, matches, and obligations;
- complete satisfaction or accepted representation of every supported obligation;
- explicit Authorization identity and renewal-bound generation;
- explicit replay and future Consumption identities;
- explicit issuance time, expiry, and requested maximum lifetime; and
- valid freshness and all bound-input validity constraints.
PolicyDecision.allow is necessary but insufficient for Authorization.
Issuance MUST NOT trust caller-provided outcome or constrained scope. It MUST compare the supplied Decision to the exact Evaluation Input and Policy Snapshot, resolve the exact Policy, re-evaluate it deterministically, resolve the exact Tool Definition from the exact Registry Snapshot, recheck identity and request continuity, recompute final scope, process every obligation, and validate lifetime and freshness. A mismatch rejects without a partial artifact.
Deny and require-confirmation Decisions are ineligible. Phase 1–6 does not collect confirmation and cannot convert require confirmation into allow.
At issuance, effective Authorization Capabilities MUST equal:
Tool Definition maximum
INTERSECTION authenticated Host Authority
INTERSECTION authenticated Intent ceiling
INTERSECTION explicitly requested Capabilities
INTERSECTION Policy-constrained Capabilities
Effective Authorization Resources MUST equal:
canonical argument-derived Resources
INTERSECTION authenticated Host Authority
INTERSECTION authenticated Intent ceiling
INTERSECTION explicitly requested Resources
INTERSECTION Policy-constrained Resources
Issuance MUST recompute both intersections exactly. It MUST NOT use union, omit a ceiling, infer a grant, expand a wildcard, or allow a caller to select a different broader or under-bound subset. The issued scope MUST equal the recomputed scope and the exact constrained scope in the Policy Decision.
Empty Resource scope means exactly no Resource authority. A Resource-bearing Canonical Request cannot produce Resource-free Authorization, and a Resource-free request cannot acquire a Resource. The accepted baseline requires nonempty Capability ceilings for Host Authority, Intent, and requested scope. An empty Policy Capability constraint permits no Capability, so it denies a nonempty request; it cannot produce an empty-scope allow Authorization.
Authorization is complete controlled immutable structural evidence. It binds:
- the exact Authorization identity, representation version, and positive renewal-bound generation;
- the exact Host authority domain and Host Authority ceiling;
- exact subject, tenant, session state, and optional delegation;
- the complete Policy Decision, Evaluation Input, Canonical Request, Tool Definition, Registry Snapshot, and Policy Snapshot;
- complete Tool Definition, Schema, canonicalization, typed argument, Resource, Proposal Assessment, Intent, Security Context, Provenance, and Influence continuity through those exact values;
- exact effective Capabilities and Resources;
- exact evaluation time and Intent renewal generation;
- inclusive issuance time, exclusive expiry, and maximum lifetime;
- exact replay identity and its request/identity correlation scope;
- exact future Consumption identity and complete Authorization Consumption Binding;
- the mandatory atomic-single-use Host contract; and
- exact reasons and supported obligations retained within the complete Policy Decision.
State is not omitted merely because canonicalization-v1 bytes do not represent it. Materially different Authorization values MUST remain structurally distinct.
Only the controlled issuer constructs Authorization. No arbitrary public construction path is conforming. Authorization content is immutable and has no callback, endpoint, executable behavior, credential, or secret. This baseline claims neither cryptographic authenticity nor portability. Possession alone is not permission to execute, and issuance performs no side effect.
The protocol uses these explicit time values:
- evaluation time: the time bound into Evaluation Input;
- issuance time: the inclusive start of Authorization lifetime;
- expiry time: the exclusive end of Authorization lifetime;
- validation time: the explicit time supplied for one Validation;
- maximum Authorization lifetime: the smaller applicable ceiling from the Host request and the global 3,600-second bound; and
- maximum evaluation age: each positive bounded freshness obligation retained by the exact Policy Decision.
All time values are explicit Host inputs. No ambient clock is read, and explicit time is not trusted time.
Issuance time MUST be at or after evaluation time. It MAY be later when the difference is within every applicable maximum-evaluation-age obligation. Each such obligation MUST be positive and no greater than 3,600 seconds. The age comparison is inclusive: an age exactly equal to the bound is valid. Subtraction occurs only after verifying that issuance is not earlier than evaluation; invalid ordering or arithmetic that cannot be represented MUST reject.
Expiry MUST be later than issuance. Authorization duration MUST NOT exceed the Host-requested maximum or 3,600 seconds. Expiry MUST NOT exceed Intent, Security Context, or applicable Host-attestation expiry. Issuance is inclusive and expiry is exclusive. Validation time before issuance or at or after expiry rejects.
ADR-0041 supersedes ADR-0033 only where ADR-0033 required issuance time to equal evaluation time. That equality rule is historical and MUST NOT be reintroduced. ADR-0033's finite duration, bound-input expiry, explicit Validation time, inclusive issuance boundary, and exclusive expiry boundary remain active. Validation MUST recheck issuance no earlier than evaluation and every retained maximum-evaluation-age obligation.
This section specifies time representation and deterministic comparison only. It does not specify a trusted clock, rollback protection, or time attestation.
Obligations are inert structured requirements bound into rule, Decision, and issuance continuity. They are not callbacks and grant no authority. Unknown, unsupported, removed, substituted, weakened, duplicated, or excessive obligations prevent conforming publication or issuance.
The accepted Phase 1–6 obligations are:
| Obligation | Issuance treatment |
|---|---|
| Require confirmation | Reject; Phase 7 confirmation collection does not exist |
| Maximum evaluation age | Require a positive value no greater than 3,600 seconds and enforce it at issuance and Validation |
| Require complete Influence boundary | Require the exact named boundary to exist with validated complete status |
| Require single-use Authorization | Bind the mandatory atomic-single-use Host contract; no Consumption is performed |
| Require audit event | Reject because Phase 1–6 cannot prove that an audit event exists |
Obligations MUST remain exactly present through complete Policy Decision, Authorization, and Validation continuity. Confirmation-related content remains structurally unresolved and does not define approval behavior. Obligations MUST NOT depend on hidden runtime code, mutable ambient state, or side effects.
Replay Identity is an explicit bounded Host-supplied correlation identifier. It is bound into Authorization but is not proof of randomness, uniqueness, reservation, replay prevention, or Consumption.
The limited replay correlation scope binds the Authorization identity, subject, tenant, session, optional delegation, and exact Canonical Request. Equal replay identifiers do not make distinct Authorizations equal.
The complete Authorization Consumption Binding is the logical structural value a future Host-owned atomic store MUST compare. It contains:
- exact Authorization identity, representation version, and generation;
- the complete Authorization binding, including complete Policy Decision, Evaluation Input, Canonical Request, Tool Definition, Host Authority, Registry Snapshot, Policy Snapshot, subject, tenant, session, and delegation;
- Proposal Assessment, Intent, Security Context, exact Policy content, and all other state transitively retained by those complete values;
- exact effective Capability and Resource scope;
- exact lifetime and freshness, including evaluation time and renewal state;
- exact replay and future Consumption identities; and
- the mandatory atomic-single-use Consumption contract.
Materially different Authorizations MUST remain structurally distinct even when their descriptive Authorization, replay, or Consumption identifiers are equal. The Consumption Binding is not a receipt, reservation, uniqueness proof, store operation, mutation, or evidence that Consumption occurred.
Phase 1–6 implements no durable store and no atomic Consumption transition. A future Host facility MUST define namespace and collision handling and atomically reject a second successful Consumption of the complete logical binding. This section defines neither persistence nor a storage algorithm.
Authorization Validation Context is the Host-controlled independent expectation set for one Validation. It contains:
- independently expected Authorization identity;
- expected Authorization version and renewal-bound generation;
- exact expected Policy Decision and Evaluation Input;
- exact expected Canonical Request and Tool Definition;
- complete expected Registry and Policy Snapshots;
- expected subject, tenant, session, and optional delegation;
- exact expected effective Capabilities and Resources;
- expected issuance time, expiry, and maximum lifetime;
- expected replay and future Consumption identities; and
- an explicit Validation time supplied separately to the Validation transition.
The independently retained Host Capability Boundary is also supplied separately; it MUST NOT be recovered from Authorization. Exact private-domain identity is required.
Proposal Assessment, Intent, Security Context, policy content, evaluation time, freshness obligations, renewal state, and the complete expected Consumption Binding are determined by the complete independently expected values above. The accepted baseline does not duplicate them as separate context fields. Validation reconstructs the complete Consumption Binding from the exact checked constituents and compares it to the artifact's binding.
Self-consistency is insufficient. A Host that copies expectations blindly from the artifact under Validation has not supplied independent expectations and is not conforming. In particular, expected Authorization identity MUST originate independently from the artifact.
Validation is pure deterministic complete structural comparison. It MUST:
- establish that the Evaluation Input and Policy Snapshot remain bound to the independently retained Host Capability Boundary;
- compare exact Authorization identity, version, and renewal-bound generation;
- compare exact Policy Decision, Evaluation Input, Canonical Request, Tool Definition, Registry Snapshot, Policy Snapshot, subject, tenant, session, delegation, effective scope, lifetime, replay identity, and Consumption identity against the independent expectations;
- verify complete Proposal Assessment, Schema, Intent, Security Context, Provenance, Influence, Host Authority, and policy-content continuity through the exact complete bound values;
- resolve the exact Policy and Tool Definition again and deterministically re-evaluate the Policy Decision;
- recompute exact intersection-only Capabilities and Resources;
- verify exact freshness and evaluation-time continuity;
- verify issuance time is not earlier than evaluation time;
- recheck every retained maximum-evaluation-age obligation;
- verify finite duration and every bound-input expiry;
- apply inclusive issuance and exclusive expiry at the explicit Validation time;
- verify replay correlation scope and the mandatory single-use contract; and
- reconstruct and compare the complete Authorization Consumption Binding.
Invalid ordering is rejected before subtraction. Unsupported versions, invalid duration, excessive age, stale input, future-invalid state, overflow, or any mismatch rejects the entire Validation.
Validation has no partial success, repair, normalization, mutation, reservation, durable replay check, Consumption, or execution. Identical complete inputs produce identical results. Successful Validation returns controlled structural evidence, the complete future Consumption Binding, and the mandatory Host atomic-single-use requirement. It is neither a grant nor replay protection.
Any Authorization validly issued under this contract MUST validate when supplied with the exact corresponding independent Validation Context, the same Host Capability Boundary, and an explicit Validation time within its lifetime. Any mutation or substitution of security-relevant state MUST reject.
| Case | Issuance result | Validation result | Reason |
|---|---|---|---|
| Issuance time equals evaluation time | Succeeds when all other checks pass | Succeeds at or after issuance and before expiry | Equality is a valid no-earlier-than case |
| Later issuance within maximum evaluation age | Succeeds | Succeeds with exact expectations | Later issuance is permitted by ADR-0041 |
| Later issuance at exact maximum-age boundary | Succeeds | Succeeds with exact expectations | Age comparison is inclusive |
| Later issuance beyond maximum age | Rejects | No valid artifact; any substituted artifact rejects | Freshness obligation exceeded |
| Issuance before evaluation | Rejects | No valid artifact; inconsistent state rejects | Issuance MUST NOT precede evaluation |
| Issuance-time mutation | Original issuance can succeed; mutation is not controlled issuance | Rejects | Exact lifetime expectation and complete binding differ |
| Evaluation-time mutation | Substituted input cannot satisfy exact Decision continuity | Rejects | Evaluation Input and freshness continuity differ |
| Freshness-obligation mutation or removal | Substituted Policy/Decision cannot satisfy exact issuance continuity | Rejects | Complete Policy content and Decision differ |
| Validation exactly at issuance | Succeeds | Succeeds | Issuance boundary is inclusive |
| Validation exactly at expiry | Succeeds before the later Validation attempt | Rejects | Expiry boundary is exclusive |
| Repeated identical Validation | One controlled artifact was issued | Every Validation returns the same result | Validation is deterministic and non-consuming |
A successful Validation result attests only that one controlled Authorization matched the supplied independent structural expectations at the explicit Validation time. It carries no executable behavior, performs no Consumption, reserves no replay identity, proves no uniqueness, establishes no cryptographic authenticity, and establishes no trusted time. It MUST NOT be reused as implicit execution permission.
| State | Meaning |
|---|---|
| Valid Authorization | A controlled artifact satisfying complete issuance and current independent Validation preconditions; it remains unconsumed and non-executable |
| Successful Validation | Controlled evidence that the artifact exactly matched independent expectations and explicit time |
| Successful Consumption | A future Host atomic state transition accepting the complete logical binding exactly once; not implemented here |
| Execution | A later Host-owned side effect after every required check and successful Consumption; outside SecureToolKit |
The Host MUST complete successful atomic Consumption before a protected side effect. Validation cannot substitute for it.
This slice fails closed as follows:
| Failure | Required result |
|---|---|
| Missing Policy Snapshot or Policy | Deny or reject without Authorization eligibility |
| Unknown Policy version or unsupported Policy content | Deny or reject without an authoritative partial Decision |
| Policy-content or Snapshot substitution | Reject exact continuity |
| Mixed Host authority domains | Reject before rule evaluation or issuance |
| Unsupported or indeterminate condition | Reject publication, or deny when evidence is indeterminate |
| No matching eligible allow | Deny |
| Matched deny | Deny regardless of confirmation or allow matches |
| Require-confirmation outcome | No Authorization; Phase 1–6 cannot satisfy it |
| Unsupported, removed, or weakened obligation | Reject publication, issuance, or Validation as applicable |
| Stale Evaluation Input or excessive evaluation age | Reject issuance or Validation |
| Issuance before evaluation, invalid expiry, or excessive lifetime | Reject issuance or Validation |
| Arithmetic overflow or invalid subtraction ordering | Reject before arithmetic is used authoritatively |
| Capability or Resource scope excess or mismatch | Deny or reject; never broaden or return a partial scope |
| Authorization identity mismatch | Reject Validation |
| Request, Proposal Assessment, Tool, Registry, Schema, Intent, or identity substitution | Reject exact continuity |
| Policy or Policy Decision substitution | Reject exact continuity and re-evaluation |
| Capability or Resource substitution | Reject exact recomputation or expectation comparison |
| Replay identity or Consumption identity substitution | Reject Validation |
| Complete Consumption Binding substitution | Reject Validation |
| Validation at or after expiry, or before issuance | Reject Validation |
| Required future atomic Consumption facility absent or unavailable | Structural Validation can succeed, but the Host MUST NOT perform the protected side effect |
No failure MAY return a partial authority-bearing Policy Decision, Authorization, or Validation result. A deny Decision carries empty constrained scope. An unavailable future facility never permits a weaker execution path.
This table is a non-normative summary of requirements stated in Sections 19–33; it establishes no additional requirement.
| Property | Classification | Established meaning |
|---|---|---|
| Immutable exact Policy selection | Implemented core guarantee | Snapshot identity, generation, complete content, lifecycle, and Host domain are exact |
| Deterministic Policy evaluation | Implemented core guarantee | Closed bounded conditions evaluate without ambient state or side effects |
| Deny precedence | Implemented core guarantee | Deny dominates require confirmation, which dominates allow |
| Allow is not Authorization | Implemented core guarantee | Only controlled issuance can construct Authorization |
| Exact policy-content continuity | Implemented core guarantee | Decisions, issuance, and Validation retain and compare complete content |
| Issuer-only Authorization construction | Implemented core guarantee | Public arbitrary construction is unavailable |
| Restriction of issuer access | Host integration obligation | The Host MUST expose issuance only through authenticated control flow |
| Intersection-only issued scope | Implemented core guarantee | Every Capability and Resource remains in every applicable ceiling |
| Explicit freshness and finite lifetime | Implemented core guarantee | Explicit values and bounded comparisons are enforced |
| Trustworthy time and rollback protection | Future Host facility | Explicit time is not trusted time |
| Independently expected Authorization identity | Host integration obligation | The Host MUST source the expected identity independently of the artifact |
| Complete structural Validation | Implemented core guarantee | Every accepted exact binding is compared and key state is recomputed |
| Validation is non-consuming | Implemented core guarantee | Repeated identical Validation remains identical and performs no mutation |
| Replay Identity is correlation only | Implemented core guarantee | It proves no uniqueness, reservation, or replay prevention |
| Complete Authorization Consumption Binding | Implemented core guarantee | The full logical binding is returned for future Host use |
| Atomic single-use Consumption | Future Host facility | A durable atomic store and transition remain required before execution |
| Independent expectation and boundary protection | Host integration obligation | The Host MUST retain the genuine boundary and avoid copying expectations from the artifact |
These properties complete the Phase 1–6 structural path through Authorization Validation. They do not define confirmation, replay persistence, atomic Consumption implementation, cryptographic authenticity, trusted time, revocation, audit persistence, networking, portable artifacts, execution, or a deployment profile.
This catalog summarizes the protocol invariants. The complete normative inventory and negative-test traceability remain in Security Invariants and the Invariant Test Matrix.
| ID | Invariant | Classification | Enforcement location | Failure result |
|---|---|---|---|---|
| P-001 | Model output never has final authority | Implemented core guarantee | Trust boundary and controlled constructors | Reject, deny, or withhold Authorization |
| P-002 | Proposal is not authenticated Intent | Implemented core guarantee | Intent and Evaluation Input construction | Reject missing or mismatched Intent |
| P-003 | Registry presence is not Authorization | Implemented core guarantee | Registry resolution boundary | Resolution produces only definition evidence |
| P-004 | Canonical Request is not Authorization | Implemented core guarantee | Canonical construction boundary | No grant or execution transition exists |
| P-005 | Evaluation Input is not Policy Decision | Implemented core guarantee | Evaluation Input construction | No decision is synthesized |
| P-006 | Allow is not Authorization | Implemented core guarantee | Policy/issuance boundary | Issuance prerequisites remain mandatory |
| P-007 | Authorization is not execution | Implemented core guarantee | Authorization artifact API boundary | No side effect is available |
| P-008 | Validation is not Consumption | Implemented core guarantee | Pure Validation transition | No state is reserved or mutated |
| P-009 | Authority never increases | Implemented core guarantee | Phases 2–6 continuity and scope checks | Excess scope rejects or denies |
| P-010 | Capability scope is intersection-only | Implemented core guarantee | Policy and issuance recomputation | Mismatch or missing ceiling rejects |
| P-011 | Resource scope is intersection-only | Implemented core guarantee | Canonical derivation, policy, and issuance | Mismatch or missing ceiling rejects |
| P-012 | Empty Resource scope means no authority | Implemented core guarantee | Request, policy, issuance, Validation | Wildcard interpretation rejects |
| P-013 | Unknown never means unrestricted | Implemented core guarantee | Every closed model and transition | Reject, deny, or explicit untrusted state |
| P-014 | Complete content continuity outranks identifier equality | Implemented core guarantee | Request, Decision, issuance, Validation | Substitution rejects |
| P-015 | Canonicalization-v1 bytes are not complete protocol equality | Implemented core guarantee | Complete Canonical Request comparison | Byte-only substitution rejects |
| P-016 | Host authority domains never compose implicitly | Implemented core guarantee | Host evidence, policy, issuance, Validation | Mixed domains reject |
| P-017 | Role Authority is attenuated | Implemented core guarantee | Host attestation and policy publication | Role misuse or ceiling conflict rejects |
| P-018 | Proposal Assessment continuity is exact | Implemented core guarantee | Canonical Request through Authorization | Missing or cross-proposal evidence rejects |
| P-019 | Policy content is immutable and exact | Implemented core guarantee | Snapshot, Decision, issuance, Validation | Same-ID content substitution rejects |
| P-020 | Deny takes precedence | Implemented core guarantee | Full-rule policy evaluation | Terminal deny Decision |
| P-021 | Unsupported obligations fail closed | Implemented core guarantee | Publication, issuance, Validation | Reject or withhold Authorization |
| P-022 | Authorization lifetime is finite | Implemented core guarantee | Issuance and Validation | Invalid or expired artifact rejects |
| P-023 | Issuance time cannot precede evaluation time | Implemented core guarantee | Issuance and Validation freshness checks | Reject as future-invalid state |
| P-024 | Validation expectations are independently supplied | Mandatory Host integration obligation | Host Validation integration | Integration is non-conforming if copied blindly |
| P-025 | Expected Authorization identity is independent | Mandatory Host integration obligation | Validation Context | Identity mismatch rejects |
| P-026 | Validation is pure and repeatable | Implemented core guarantee | Validation transition | Identical inputs yield identical results |
| P-027 | Replay Identity is correlation only | Implemented core guarantee | Authorization replay binding | No replay-prevention claim arises |
| P-028 | Atomic Consumption precedes execution | Future Host facility | Host storage/execution boundary | Execution MUST remain blocked if unavailable |
| P-029 | No partial authority-bearing artifact is returned | Implemented core guarantee | All controlled transitions | Whole transition rejects or denies |
| P-030 | Host evidence is authentic and accurately scoped | Mandatory Host integration obligation | Authentication and evidence adapters | Host MUST withhold trusted construction |
| P-031 | Time is trustworthy and rollback-resistant | Production deployment prerequisite | Future Host time integration | Production execution MUST remain blocked |
| P-032 | Artifacts are authentic and single-use across failures | Production deployment prerequisite | Future authenticity and Consumption facilities | Production execution MUST remain blocked |
Core enforcement validates explicit structure and equality. It cannot prove that the Host authenticated a human, supplied truthful evidence or time, protected the genuine boundary, or atomically consumed Authorization. Those are explicit Host obligations or absent production facilities, not implicit core guarantees.
This table summarizes the normative transitions and failure rules stated in the preceding sections; it does not create an additional transition.
| Artifact or state | Permitted constructor or authority | Valid predecessor | Valid successor | Authority status | Terminal failure behavior |
|---|---|---|---|---|---|
| Raw Proposal | Model or untrusted caller | None | Exact Registry resolution and Schema validation | Untrusted; no authority | Reject malformed or unresolved input |
| Resolved Tool Definition | Exact immutable Registry Snapshot | Raw Proposal identity plus exact lookup | Schema validation | Ceiling evidence only | Unknown, retired, stale, or ambiguous lookup rejects |
| Validated typed arguments | Closed Schema validator | Resolved definition plus occurrence-preserving input | Canonical Request | Validated meaning; no authority | Whole validation rejects |
| Proposal Assessment | Restricted Host assessment path | Raw Proposal plus retained Host boundary | Canonical Request and lineage validation | Controlled correlation; no grant | Mismatch or mixed domain rejects |
| Canonical Request | Canonical request constructor | Validated arguments, exact definition, exact assessment | Evaluation Input | Controlled request evidence only | No partial request |
| Authenticated Host evidence | Role-authorized Host validators | Raw claims, authority ceiling, boundary, explicit time | Security Context, Intent, lineage, Evaluation Input | Authenticated facts and ceilings only | Missing, stale, mixed, or excessive evidence rejects |
| Evaluation Input | Complete-input validator | Exact request, Host evidence, Intent, lineage, requested scope | Policy evaluation | Authority-bearing input; no Decision | Whole construction rejects |
| Policy Snapshot | Policy-administration Role Authority | Valid bounded draft and Host domain | Exact policy evaluation | Immutable narrowing rules; no grant | Publication or lookup rejects |
| Policy Decision: deny | Deterministic evaluator | Evaluation Input plus exact Snapshot | Terminal denial | No authority | Authorization is impossible |
| Policy Decision: require confirmation | Deterministic evaluator | Evaluation Input plus exact Snapshot | Future Phase 7 only | Unresolved; not allow | Phase 1–6 issuance rejects |
| Policy Decision: allow | Deterministic evaluator | Evaluation Input plus exact Snapshot | Controlled issuance | Necessary evidence; insufficient authority | Issuance rechecks or rejects |
| Authorization | Controlled issuer | Exact eligible allow Decision and complete issuance inputs | Structural Validation | Scoped structural evidence; not execution | No artifact on failure; immutable after issuance |
| Successful Validation | Pure validator | Authorization plus independent expectations, boundary, and time | Future Host Consumption | Structural agreement only | Does not reserve or consume |
| Failed Validation | Pure validator | Mismatched, invalid, future, or expired artifact/context | Terminal failure or new complete attempt | No authority | No repair or partial success |
| Future Consumption | Future Host atomic facility | Successful Validation and complete Consumption Binding | Host execution | Single-use state transition | Missing, duplicate, failed, or indeterminate result blocks execution |
| Execution | Host-owned Executor | Successful Validation and successful atomic Consumption | External side effect | Host-owned side effect | No protected effect on any unmet prerequisite |
Implemented transitions end at successful structural Validation. Future Consumption and execution are shown only to make the mandatory boundary clear; Phase 1–6 implements neither.
The following transitions are impossible or prohibited:
- Proposal directly to Authorization;
- Policy allow directly to execution;
- Validation directly to execution without successful atomic Consumption;
- require confirmation to Authorization in Phase 1–6;
- failed Validation to repaired success without a new complete attempt;
- Authorization to mutated Authorization;
- Replay Identity to authority, reservation, or Consumption evidence; and
- any deny, missing evidence, or unknown version to a permissive fallback.
| Stage | Fail-closed conditions | Result; partial output prohibition |
|---|---|---|
| Registry resolution | Malformed or unknown identity/version, excessive limits, retired lifecycle, stale Snapshot, ambiguity, substitution | Reject resolution; no fallback or partial definition |
| Schema validation | Unknown version/type/field/enum, duplicate field, missing required value, coercion need, excessive structure, ambiguous input | Reject all arguments; no partial Canonical Request |
| Canonical Request construction | Definition, Schema, Proposal, assessment, domain, version, or size mismatch | Reject construction; no alternate canonical form |
| Proposal Assessment | Malformed or sensitive identifier, wrong Proposal, duplicate/excess lineage identity, mixed domain | Reject assessment continuity; no trust upgrade |
| Host evidence | Missing role, wrong issuer/fact/scope, stale validity, mixed domain, substitution, duplicate/excess evidence | Reject controlled evidence; raw claim remains untrusted |
| Evaluation Input | Missing, stale, mismatched, excessive, mixed-domain, incomplete, or substituted required fact | Reject complete transition; no partial input |
| Policy | Missing/unknown/retired policy, unsupported structure, indeterminate condition, no allow, deny precedence, scope loss, mixed domain | Return complete deny Decision where defined, otherwise reject evaluation; never partial allow |
| Issuance | Non-allow outcome, unsupported obligation, mismatch, scope excess, stale input, invalid time/lifetime, substitution | Reject; no Authorization |
| Validation | Any independent-expectation, domain, identity, policy, request, scope, freshness, lifetime, replay, or binding mismatch | Failed Validation; no result or repair |
| Consumption | Facility unavailable, duplicate, failed, indeterminate, non-atomic, or wrong complete binding | Block execution; no success MAY be inferred |
| Execution | Missing valid artifact, failed Validation, absent successful Consumption, executor/request mismatch | No protected side effect |
A rejected transition produces no successor controlled artifact. A deny Policy Decision is complete non-authoritative evidence that issuance is ineligible. An invalid Authorization is an artifact that fails required expectations or temporal checks and cannot advance. Failed Validation produces no successful Validation evidence. Blocked execution means the Host performs no protected side effect.
Fail-closed behavior MUST NOT be replaced by fallback version selection, semantic repair, permissive defaults, wildcard scope, best-effort Authorization, partial authority, or execution followed by later audit.
Controlled evidence stores only the bounded information required for exact protocol continuity. It MUST NOT store raw prompts as controlled evidence. Proposal Assessment and its identifiers MUST NOT contain raw prompts, documents, tool output, raw argument values, credentials, or secrets. Security Context MUST contain classifications and references rather than credentials, tokens, or raw identity-provider assertions.
Provenance stores privacy-safe source, custody reference, transformations, and verification state, not raw content. Influence stores bounded privacy-safe identities, kinds, relationships, evidence references, and collection boundaries, not raw influenced material. Intent display metadata and Tool display metadata are bounded and non-authoritative. Policy reasons and errors use closed stable categories and public limits without echoing rejected values.
Correlation identifiers identify protocol objects; they are not content storage. Audit correlation is distinct from retaining prompts, documents, raw argument values, or evidence payloads. Host-provided identifiers MUST avoid personal data, credentials, secrets, raw content, and sensitive business values. Exact structural equality requires exact protocol state, not storage of raw Model text.
The Host remains responsible for secure storage, log redaction, retention and deletion policy, access control, regulatory handling, breach response, and any external audit-system privacy design. This section defines no audit event, sink, persistence, integrity chain, or retention mechanism.
Limits marked Protocol are owned by accepted phase decisions or ADRs and are required for Phase 1–6 semantic conformance. A conforming implementation MUST NOT exceed them. Limits marked Reference are enforced and tested by the Swift baseline but lack a separately accepted numeric protocol owner. Another implementation MAY choose a different finite deterministic Reference bound if it documents the bound, enforces it fail closed, exceeds no Protocol maximum, discloses the difference in any interoperability claim, and remains compatible with canonicalization v1 and the normative vectors in Section 51.
Host deployment limits are tighter operational limits outside the protocol core. They MUST fail closed and MUST NOT widen a Protocol maximum or redefine protocol semantics. No Reference-class number is a universal maximum merely because the Swift baseline enforces it.
Every exceeded core limit rejects before truncation or partial controlled output.
| Area and item | Exact inclusive bound and scope | Class | Failure | Controlling record |
|---|---|---|---|---|
| Tool Identifier total | Maximum 128 ASCII bytes per identifier; zero is not accepted and the minimum is determined by the Section 49 Tool Identifier grammar | Protocol | Reject identity | Phase 2; ADR-0012 |
| Tool Identifier segments | 2–8 segments inclusive per identifier; zero is not accepted | Protocol | Reject identity | Phase 2; ADR-0012 |
| Tool Identifier segment | 1–32 ASCII bytes inclusive per segment; zero bytes is not accepted | Protocol | Reject identity | Phase 2; ADR-0012 |
| Tool or Registry Snapshot numeric generation text | 1–20 decimal ASCII digits inclusive per generation, representing 1–2^64−1 inclusive; zero is not accepted | Protocol | Reject version | Phase 2; ADR-0012–0013 |
| Definition or Registry Snapshot identity | 1–64 restricted ASCII bytes inclusive per identity; zero bytes is not accepted | Protocol | Reject identity | Phase 2; ADR-0013 |
| Definitions per Registry Snapshot | 0–1,024 definitions inclusive per Snapshot; zero is accepted and lookup then fails closed | Protocol | Reject publication without a partial Snapshot | Phase 2; ADR-0013 |
| Capabilities per Tool Definition | 1–16 unique Capabilities inclusive per definition; zero is not accepted | Protocol | Reject definition | Phase 2; ADR-0015 |
| Tool display title | 1–80 printable ASCII bytes inclusive per title; zero bytes is not accepted | Protocol | Reject metadata | Phase 2; ADR-0015 |
| Tool safe summary | 1–240 printable ASCII bytes inclusive per summary; zero bytes is not accepted | Protocol | Reject metadata | Phase 2; ADR-0015 |
| Documentation reference | 1–64 restricted ASCII bytes inclusive per present reference; absence is accepted, but a present zero-byte value is not | Protocol | Reject metadata | Phase 2; ADR-0015 |
| Schema identity | 1–64 restricted ASCII bytes inclusive per identity; zero bytes is not accepted | Protocol | Reject Schema | Phase 3; ADR-0016 |
| Field or enumeration name | 1–64 restricted ASCII bytes inclusive per name; zero bytes is not accepted | Protocol | Reject Schema/input | Phase 3; ADR-0016, ADR-0018 |
| Object fields | 0–64 fields inclusive per object Schema and per object input; zero is accepted | Protocol | Reject without truncation | Phase 3; ADR-0016 |
| Enumeration cases | 1–64 cases inclusive per enumeration Schema; zero is not accepted | Protocol | Reject Schema | Phase 3; ADR-0016 |
| Array elements | 0–64 elements inclusive per array value; zero is accepted | Protocol | Reject value without truncation | Phase 3; ADR-0016 |
| String value | 0–1,024 printable ASCII bytes inclusive per string; zero is accepted | Protocol | Reject value | Phase 3; ADR-0019 |
| Signed integer value | −2^63 through 2^63−1 inclusive per value; zero is accepted | Protocol | Reject type/value outside domain; no coercion | Phase 3; ADR-0019 |
| Unsigned integer value | 0 through 2^64−1 inclusive per value; zero is accepted | Protocol | Reject type/value outside domain; no coercion | Phase 3; ADR-0019 |
| Schema nesting depth | 1–8 levels inclusive per Schema tree, counting the root; zero is not a constructed Schema | Protocol | Reject Schema | Phase 3; ADR-0016 |
| Inline Schema nodes | 1–256 nodes inclusive per complete Schema tree, including the root; zero is not a constructed Schema | Protocol | Reject Schema | Phase 3; ADR-0016 |
| Canonical Request bytes | Maximum 65,536 bytes per complete request; zero is not accepted and the minimum is determined by the Section 47 envelope grammar | Protocol | Reject construction without truncation or partial bytes | Phase 3; ADR-0017 |
| Restricted Phase 4 identity | 1–64 restricted ASCII bytes inclusive per identity; zero bytes is not accepted | Protocol | Reject identity/evidence | Phase 4; ADR-0020–0024 |
| Proposal Assessment provenance identities | 0–64 unique identities inclusive per assessment; zero is accepted | Protocol | Reject assessment | ADR-0037 using Phase 4 provenance bound |
| Proposal Assessment Influence collection identities | 0–8 unique identities inclusive per assessment; zero is accepted | Protocol | Reject assessment | ADR-0037 using Phase 4 collection bound |
| Applicable validated attestations | Maximum 16 attestations per validation/input collection; zero is not accepted for complete Evaluation Input and the minimum is determined by the facts and roles required by the applicable construction rule | Protocol | Reject evidence/input without a partial controlled value | Phase 4; ADR-0021 |
| Role Authorities supplied for attestation composition | 1–16 authorities inclusive per composition in the Swift reference; zero is not accepted | Reference | Reject composition | Swift RC0.2 implementation; ADR-0036 requires bounded composition but sets no number |
| Closed Role Authority kinds | Exactly 6 supported role tokens in the protocol vocabulary; zero or unknown kinds are not accepted as a role | Protocol | Reject unknown or duplicate role | ADR-0036 and accepted closed model |
| Authentication methods in Security Context | 0–8 unique methods inclusive per Context; zero is accepted | Protocol | Reject Context | Phase 4; ADR-0021 |
| Host, intended, or requested Capabilities | 1–8 unique Capabilities inclusive per applicable scope; zero is not accepted | Protocol | Reject authority, Intent, or input | Phase 4; ADR-0020, ADR-0024, ADR-0035 |
| Host, intended, or requested Resources | 0–16 unique Resources inclusive per applicable scope; zero is accepted only with exact resource-free semantics | Protocol | Reject authority, Intent, or input | Phase 4; ADR-0020, ADR-0024, ADR-0035, ADR-0038 |
| Provenance records | 0–64 records inclusive per validated Provenance set; zero is accepted as unknown coverage | Protocol | Reject lineage | Phase 4; ADR-0022 |
| Transformations per Provenance record | 0–8 transformations inclusive per record; zero is accepted | Protocol | Reject lineage | Phase 4; ADR-0022 |
| Influence records | 0–64 records inclusive per validated Influence set; zero is accepted | Protocol | Reject lineage | Phase 4; ADR-0023 |
| Influence edges | 0–128 parent edges inclusive in aggregate per validated Influence set; zero is accepted | Protocol | Reject graph | Phase 4; ADR-0023 |
| Influence collection boundaries | 0–8 boundaries inclusive per validated Influence set; zero is accepted | Protocol | Reject lineage | Phase 4; ADR-0023 |
| Non-authoritative Intent display text | Absent or 1–160 printable ASCII bytes inclusive per present value; a present zero-byte value is not accepted | Protocol | Reject Intent | Phase 4; ADR-0020 |
| Explicit epoch second | 0–4,102,444,800 seconds since the Unix epoch inclusive per time value; zero is accepted | Protocol | Reject time | Phase 4; ADR-0024 |
| Policy-family identity | 1–64 restricted ASCII bytes inclusive per identity; zero bytes is not accepted | Protocol | Reject publication | Phase 5; ADR-0025–0026 |
| Policies per Policy Snapshot | 1–32 Policy Definitions inclusive per Snapshot; zero is not accepted | Protocol | Reject publication without a partial Snapshot | Phase 5; ADR-0026 |
| Rules per Policy | 1–128 rules inclusive per Policy Definition; zero is not accepted | Protocol | Reject Policy | Phase 5; ADR-0025 |
| Aggregate rules per Policy Snapshot | 1–512 rules inclusive across all Policy Definitions in one Snapshot; zero is not accepted | Protocol | Reject publication without truncation or a partial Snapshot | Phase 5; ADR-0025–0026, ADR-0040 |
| Aggregate condition nodes per Policy Snapshot | 1–8,192 nodes inclusive across every rule in one Snapshot; zero is not accepted | Protocol | Reject publication without truncation or a partial Snapshot | Phase 5; ADR-0025–0026, ADR-0040 |
| Condition nodes per rule | 1–64 nodes inclusive per complete rule condition tree, counting the root; zero is not accepted | Protocol | Reject rule | Phase 5; ADR-0025 |
| Condition depth | 1–8 levels inclusive per rule condition tree, counting the root; zero is not accepted | Protocol | Reject rule | Phase 5; ADR-0025 |
Children per all or any |
1–16 children inclusive per compound node; zero is not accepted | Protocol | Reject rule | Phase 5; ADR-0025 |
| Obligations per rule | 0–8 obligations inclusive per rule; zero is accepted | Protocol | Reject rule | Phase 5; ADR-0029 |
| Unique obligations per Decision | 0–128 obligations inclusive in aggregate per Decision; zero is accepted | Protocol | Deny with limit reason and no partial non-deny Decision | Phase 5; ADR-0029 |
| Reasons per Decision | 1–128 reasons inclusive in aggregate per Decision; zero is not accepted because every Decision has a stable outcome reason | Protocol | Deny with limit reason and no partial non-deny Decision | Phase 5; ADR-0029 |
| Matched rule identities per Decision | 0–128 identities inclusive in aggregate per Decision; zero is accepted | Protocol | Deny with limit reason and no partial non-deny Decision | Phase 5; ADR-0029 |
| Capabilities per policy constraint | 0–16 unique Capabilities inclusive per constraint; zero is accepted and permits no Capability | Protocol | Reject an excessive or duplicate constraint | Phase 5; ADR-0028 |
| Capabilities per collection-valued policy predicate operand | 1–16 unique Capabilities inclusive per operand; zero is not accepted | Protocol | Reject rule at publication | Phase 5; ADR-0025, ADR-0028 |
| Resources per policy constraint | 0–32 unique Resources inclusive per constraint; zero is accepted and permits no Resource | Protocol | Reject an excessive or duplicate constraint | Phase 5; ADR-0028 |
| Resources per collection-valued policy predicate operand | 1–32 unique Resources inclusive per operand; zero is not accepted | Protocol | Reject rule at publication | Phase 5; ADR-0025, ADR-0028 |
| Assurance/method/trust predicate operand | Respectively 1–6, 1–6, or 1–3 unique closed values inclusive per operand; zero is not accepted | Reference | Reject rule at publication | Swift bounded closed-vocabulary implementation; no separate numeric ADR owner |
| Maximum Influence-count predicate operand | 0–64 records inclusive per operand; zero is accepted | Protocol | Reject rule at publication | Phase 4 Influence bound applied by Phase 5 |
| Maximum Intent/Context age operand | 0–2^64−1 seconds inclusive per operand; zero is accepted | Reference | Indeterminate on future issue time; otherwise exact compare | Swift representation; no separate numeric ADR owner |
| Maximum evaluation-age obligation | 1–3,600 seconds inclusive per obligation; zero is not accepted | Protocol | Reject publication, issuance, or Validation | ADR-0041 |
| Authorization-family identity | 1–64 restricted ASCII bytes inclusive per identity in the Swift reference; zero bytes is not accepted | Reference | Reject identity | Swift Phase 6 public limit and tests; ADR-0034 specifies bounded identity without number |
| Authorization scope expectation Capabilities | 0–16 unique Capabilities inclusive per expectation in the Swift reference; zero is accepted | Reference | Reject expectation | Swift Phase 6 public limit; actual issued scope inherits tighter Phase 4 bounds |
| Authorization scope expectation Resources | 0–32 unique Resources inclusive per expectation in the Swift reference; zero is accepted | Reference | Reject expectation | Swift Phase 6 public limit; actual issued scope inherits tighter Phase 4 bounds |
| Authorization maximum lifetime | 1–3,600 seconds inclusive per issuance request and Authorization; zero is not accepted | Protocol | Reject request, issuance, or Validation | ADR-0033 as amended by ADR-0041 |
| Authorization representation version | Exactly version 1; zero and every other version are unsupported | Protocol | Reject unsupported version | Phase 6; ADR-0030–0031 |
| Authorization renewal generation | 1–2^64−1 inclusive per Authorization; zero is not accepted | Protocol | Reject mismatch | Phase 6; ADR-0031 |
There is no accepted aggregate byte limit for complete Evaluation Input, Policy Decision, Authorization, or Validation result because Phase 1–6 defines no portable serialization. Bounded constituent collections still make the in-memory reference model finite. No universal Host deployment limit is accepted at this baseline.
| Threat | Protocol control | Coverage status | Residual risk |
|---|---|---|---|
| Direct prompt injection | Model output is untrusted; exact Intent, policy, and issuer required | Mitigated by implemented core | Broad Host Intent or policy can still permit harm |
| Indirect prompt injection | Provenance/Influence binding and unknown defaults | Mitigated only with conforming Host integration | Host can omit unseen Influence |
| Model hallucination | Closed Registry, Schema, exact lookup, no inferred authority | Mitigated by implemented core | Valid but harmful proposals remain policy/Intent risk |
| Confused deputy | Subject, tenant, session, delegation, Intent, Host ceilings | Mitigated only with conforming Host integration | Incorrect Host authentication or entitlement defeats facts |
| Tool confusion | Exact Tool identity/version/definition and non-authoritative display | Mitigated by implemented core | Human-facing semantic confusion remains Host UX risk |
| Version confusion | Exact generations; no latest or compatible fallback | Mitigated by implemented core | Host distribution/rollback is not enforced |
| Schema smuggling | Closed typed Schema and all-or-nothing validation | Mitigated by implemented core | Permissive Host parsing can destroy evidence |
| Duplicate-key ambiguity | Occurrence preservation and duplicate rejection | Mitigated only with conforming Host integration | Host parser MUST preserve occurrences |
| Type confusion | Exact typed values; no coercion or widening | Mitigated only with conforming Host integration | Host parser or Executor can reinterpret values |
| Capability escalation | Five-ceiling intersection and exact recomputation | Mitigated by implemented core | Overbroad Host ceilings remain possible |
| Resource escalation | Reviewed typed derivation and five-ceiling intersection | Mitigated only with conforming Host integration | Incorrect Schema resource classification remains |
| Empty-scope reinterpretation | Empty Resource scope is exactly no authority | Mitigated by implemented core | Host Executor MUST preserve empty semantics |
| Registry substitution | Complete Snapshot/definition equality | Mitigated by implemented core | No cryptographic publication authenticity |
| Schema substitution | Complete Schema retained and compared | Mitigated by implemented core | No portable cryptographic commitment |
| Proposal Assessment substitution | Exact proposal, assessment, collections, and domain | Mitigated by implemented core | Host assessment accuracy is assumed |
| Provenance laundering | Missing/unverified remains untrusted; exact role upgrade | Mitigated only with conforming Host integration | Compromised provenance authority can lie |
| Incomplete Influence collection | Boundary-local unknown/partial/complete semantics | Mitigated only with conforming Host integration | Material outside declared boundary remains unseen |
| Mixed Host-domain authority | Exact opaque boundary at every transition | Mitigated by implemented core | Genuine boundary possession remains privileged |
| Role substitution | Exact issuer, role, fact, common ceiling and domain | Mitigated by implemented core | Same-process Host MUST distribute roles safely |
| Policy substitution | Complete Snapshot/Policy equality plus re-evaluation | Mitigated by implemented core | No signatures, distribution authenticity, or revocation |
| Malicious or incomplete policy | Closed bounded rules, deny defaults, deterministic reviewability | Mitigated only with conforming Host integration | Authorized administrator can publish harmful policy |
| Confirmation bypass | Require confirmation is not allow; issuance rejects | Mitigated by implemented core | Phase 7 confirmation is absent rather than implemented |
| Stale Authorization | Core enforces finite lifetime, explicit Validation time, and structural freshness bounds | Deferred production blocker; partial structural control only | Trustworthy time and rollback resistance are absent, so a conforming Level 2 integration alone cannot establish complete mitigation |
| Issuance/evaluation-time mismatch | No-earlier-than and maximum-age checks | Mitigated by implemented core | Host can supply false time |
| Authorization identity substitution | Independently expected exact Authorization identity | Mitigated only with conforming Host integration | IDs are not authentic or unique by themselves |
| Replay | Lifetime, correlation, complete future Consumption Binding | Deferred production blocker | No durable atomic replay prevention exists |
| Validation-as-Consumption confusion | Validation is pure, repeatable, and explicitly non-consuming | Mitigated only with conforming Host integration | Host can misuse successful Validation |
| Malicious tool output | Core treats tool output as untrusted Provenance/Influence lineage input | Deferred production blocker; partial structural control only | Tool-response validation and Executor safety are absent, and Host lineage collection or downstream parsing can still fail |
| Executor mismatch | Exact request retained; execution outside core | Deferred production blocker | No deployed Executor binding or conformance proof |
| Compromised Host | Explicit trust boundary | Outside protocol guarantee | Host can fabricate facts, policy, time, or execution |
| Compromised same-process caller | Opaque retained boundary and restricted constructors | Outside protocol guarantee | Possession of genuine boundary defeats in-process discipline |
| Untrusted time | Explicit time without trust claim | Deferred production blocker | False time permits stale or future misuse |
| Rollback | Exact versions without current-state service | Deferred production blocker | Old valid state can be selected by Host |
| Distributed race | Mandatory future atomic Consumption | Deferred production blocker | No cross-process atomicity or recovery exists |
| Unavailable Consumption store | Fail-closed Host execution obligation | Deferred production blocker | Phase 1–6 cannot enforce the block itself |
Coverage means only the stated control. It does not imply prevention outside the specified trust boundary or without the required Host integration. The stale-Authorization and malicious-tool-output rows identify partial core controls only. Their complete threats remain aligned with the absent production facilities in Section 41 and cannot be closed by Level 2 conformance alone. For stale Authorization, P-022 and P-023 describe the structural controls while P-031 and Section 41 retain trustworthy time and rollback resistance as production prerequisites. For malicious tool output, Section 16 and P-013 keep unknown or unverified lineage non-authoritative while Section 41 retains tool-response validation and Executor binding as absent production facilities.
RC0_FINAL_1 is a production NO-GO. The facilities below are mandatory production prerequisites, not optional enhancements. Phase 1–6 intentionally does not implement them, and this section does not design them.
| Required facility | Why absent in Phase 1–6 | Missing security property and production impact | Assigned owner, if decided |
|---|---|---|---|
| Cryptographic artifact authenticity | The baseline is an in-process structural protocol | Artifacts cannot be authenticated across trust or process boundaries | Unassigned future protocol/Host work |
| Portable trusted artifacts | No wire format or portable commitment was selected | Structural values cannot safely cross implementations or storage boundaries | Unassigned; requires independent versioning |
| Key and trust management | No cryptographic design was approved | No issuer authentication, key rotation, trust anchor, or compromise recovery | Unassigned production profile |
| Trusted time | Time is explicit data only | Expiry and freshness can be defeated by false time | Future Host facility |
| Rollback protection | No current-state or monotonic-version service exists | Old Registry, Policy, intent, or authorization state can be reused | Future Host facility |
| Durable replay persistence | Replay Identity is correlation only | Reuse survives restart or process boundaries | Future Host facility |
| Atomic single-use Consumption | Phase 6 returns only a complete logical binding | Duplicate execution remains possible under concurrency or failure | Future Host facility, mandatory before execution |
| Revocation and current-Snapshot enforcement | No revocation or authoritative-current-state lookup exists | Previously valid authority cannot be withdrawn reliably | Future Host facility |
| Audit persistence | Phase 8 has not begun | Security transitions lack durable operational evidence | Phase 8 and Host integration |
| Audit tamper evidence | No event chain, anchoring, or sink exists | Modification, insertion, deletion, and reordering are not detectable | Phase 8 and Host deployment |
| Executor implementation binding | Execution is deliberately outside the core | A Host Executor can run a different request or skip prerequisites | Host integration; reference demonstration is Phase 9 |
| Tool-response validation | No tool protocol or response Schema is defined | Malicious, ambiguous, or mismatched output can affect later processing | Unassigned Host/tool integration |
| Distributed recovery | No storage, transaction, or coordination model exists | Crash and uncertain-outcome handling can duplicate or lose operations | Production Host operations |
| Tool-level idempotency | The core does not control side-effecting tools | Atomic Authorization use alone can leave uncertain tool outcomes unresolved | Host/tool integration |
| Cross-process authority protection | Host Capability Boundary is process-local | Same-process possession and cross-process transport lack cryptographic protection | Future isolation or authenticity work |
| Operational monitoring and incident response | No deployment or operations profile exists | Attacks, failures, and compromise can remain undetected or unmanaged | Phase 10/Host operations |
| Deployment hardening | No topology, secret, platform, or supply-chain profile exists | Secure structural semantics do not guarantee a secure deployed system | Phase 10/Host operations |
If a deployment requires any absent facility, INV-017 requires failure rather than a weaker substitute. Structural Authorization and Validation do not remove these blockers.
Later work can extend this baseline only by preserving its exact bindings and authority monotonicity:
- Phase 7 approval MUST bind a complete versioned request, Evaluation Input, Policy Snapshot, Policy Decision, subject, scope, lifetime, and Host-domain envelope. It MUST NOT replace authenticated Intent or broaden authority.
- Phase 8 audit MAY correlate privacy-safe Proposal Assessment, Decision, Authorization, Validation, future Consumption, and Host execution events. It MUST NOT require raw prompts, documents, tool output, or raw argument values by default.
- Future cryptography MUST protect a new complete versioned envelope rather than canonicalization-v1 bytes alone.
- Future trusted time MUST enter through explicit time interfaces and preserve deterministic comparison semantics.
- Future replay storage MUST consume the complete Authorization Consumption Binding, not a replay or Consumption identifier alone.
- Future revocation MUST check explicit current Host-owned state and fail closed when the required facility is unavailable.
- Future Executor verification remains Host-owned and MUST preserve the exact validated request and successful-Consumption precondition.
- Future portable formats require independent versions and MUST reject unknown content rather than infer compatibility.
These are compatibility boundaries only. They define no approval structure, user interface, signature, key, clock, store, revocation algorithm, wire format, or execution flow. Phase 7 has not started.
This section defines conformance only for the complete Phase 1–6 semantics in this document. It does not define later-phase conformance or a production deployment profile.
Level 1 requires closed typed request semantics; exact Registry, Tool Definition, Schema, Proposal Assessment, and policy continuity; canonicalization-v1 compatibility; authority monotonicity; deterministic policy evaluation; exact issuance and Validation; fail-closed behavior; no Model authorization; and no treatment of Validation as Consumption.
For Level 1, Sections 47–51 are normative interoperability requirements subject to the Protocol/Reference limit distinction in Section 39.
Level 2 includes Level 1 and requires authenticated Host evidence, correct least-authority role distribution, genuine boundary retention, accurate explicit Intent, privacy-safe lineage collection, explicit time, independently sourced Validation expectations and Authorization identity, no artifact-derived trust, and blocked execution unless future atomic Consumption succeeds.
A Level 2 claim MUST identify the integration boundary and provide every minimum evidence item below. Evidence MAY use any vendor, identity provider, process topology, or storage implementation that preserves the stated control. A missing document, positive test, negative test, or evidence artifact makes the Level 2 claim non-conforming. These criteria establish reviewable Host integration conformance; they do not establish production conformance.
| Level 2 obligation | Required documented control | Required positive integration test | Required negative integration test | Evidence artifact | Failure condition |
|---|---|---|---|---|---|
| Authenticated Host evidence | Identify each authentication/evidence authority, its trust boundary, fact classes, and exact scope | Genuine authenticated facts produce the expected controlled values | Unauthenticated, wrong-issuer, stale, or scope-mismatched facts produce no controlled value | Architecture/control document and integration test report | Any model-controlled or unauthenticated path can create trusted Host evidence |
| Role Authority distribution | Map every Role Authority to its permitted fact class and common entitlement ceiling | Separately authorized roles compose within one exact domain and ceiling | Cross-role issuance, duplicate issuer, conflicting ceiling, or mixed domain rejects | Role/authority configuration snapshot and role tests | A role can attest another role's fact or composition broadens authority |
| Host Capability Boundary retention | Document creation, ownership, lifetime, and least-authority distribution of the genuine boundary | The retained boundary completes valid same-domain transitions | Replacement, loss, parallel same-description boundary, or unauthorized distribution rejects or blocks the transition | Boundary lifecycle/control document and boundary-loss/substitution test output | The boundary is recreated, recovered from an artifact, exposed to an untrusted path, or silently replaced |
| Explicit Intent capture | Document the authenticated user-to-Intent capture path and exact request/tool scope rules | Captured Intent matching subject, session, target, scope, validity, and renewal validates | Model-derived, absent, stale, mutated, overbroad, or mismatched Intent rejects | Intent-control document and positive/negative integration report | Proposal text or semantic inference can establish Intent, or mismatch does not reject |
| Subject, tenant, session, and delegation continuity | Document the authoritative source and handoff for every applicable identity fact | Exact facts remain equal through Context, Intent, Evaluation Input, Authorization, and Validation | Mutation, omission, cross-tenant/session substitution, or delegation mismatch rejects | End-to-end continuity test vector and integration report | Any transition accepts partial or substituted identity continuity |
| Privacy-safe Provenance and Influence collection | Document collection boundaries, source/verification rules, minimization, and redaction | Expected privacy-safe lineage and boundary-local completeness validate without raw content | Missing expected lineage, false completeness, cross-boundary edges, or raw-content identifier injection rejects | Collector architecture, representative sanitized output, and lineage tests | Missing lineage becomes trusted/complete or controlled correlation identifiers contain raw argument values or other prohibited content |
| Explicit time sourcing | Document the exact source and delivery path for evaluation, issuance, and Validation times, without claiming core clock trust | Supplied times exercise valid inclusive/exclusive and maximum-age boundaries deterministically | Future evaluation, stale age, rollback-indicative input, invalid order, or unavailable required time blocks the transition | Time-source configuration snapshot and boundary test report | Ambient time is read, time is silently substituted, or invalid/unavailable time permits progress |
| Independent Validation expectations | Document where complete expected values are retained independently of the artifact | An artifact validates against the matching independently retained expectation set | Copying, mutating, omitting, or substituting an expected binding rejects or is detected as non-conforming integration | Validation architecture and expectation-substitution test report | Expectations are populated blindly from the artifact or a mismatch succeeds |
| Independently sourced AuthorizationID | Document the Host workflow source and correlation of the expected Authorization identity | The independently retained expected identity matches the intended artifact | A same-shape artifact with another or reused descriptive identity rejects | Authorization workflow record and cross-authorization substitution test | Expected identity is read from the artifact under Validation or substitution succeeds |
| No artifact-derived trust | Document every trust root and prove artifacts supply no boundary, Host evidence, time trust, or independent expectation | Valid processing uses separately retained Host inputs for every authority-bearing comparison | Artifact-only reconstruction, self-consistency, or descriptive-ID reuse fails | Trust-source inventory and artifact-derived-trust negative test | Artifact content becomes its own trust root or replaces an independent input |
| Consumption-gated execution | Document an execution gate that defaults to blocked and requires successful atomic Consumption of the complete binding | A valid structurally checked request reaches the Host gate without performing a protected side effect before successful Consumption | Missing, failed, indeterminate, duplicate, non-atomic, or wrong-binding Consumption blocks every protected side effect | Execution-blocking test report and gate/control document | Any protected side effect occurs without successful atomic Consumption of the complete binding |
Level 2 does not require a protected side effect to execute successfully. A Host without a conforming atomic Consumption facility can satisfy the final row only by keeping protected execution blocked; such a Host cannot claim Level 3 or production conformance.
Level 3 is not currently achievable from Phase 1–6 alone. It requires the production facilities in Section 41, deployment-specific assurance, and operational evidence. RC0_FINAL_1 therefore has no conforming production profile.
Swift is the current reference implementation. No external implementation is certified. Source compatibility, matching API names, similar outputs, or happy-path tests do not establish protocol conformance.
A future conformance claim requires, at minimum:
- versioned protocol test vectors, including canonicalization-v1 vectors;
- positive and negative invariant tests;
- same-identity and partial-binding substitution tests;
- exact boundary and deterministic-limit tests;
- policy precedence, indeterminate, and permutation tests;
- issuance-to-validation consistency and mutation tests;
- replay-versus-Consumption distinction tests; and
- Host integration evidence for authentication, independent expectations, privacy, time sourcing, boundary protection, Consumption, and execution blocking.
This document creates no certification authority or certification program.
This appendix is non-normative. Swift names and access-control mechanisms do not define protocol semantics. They are implementation techniques. Another language can use different mechanisms while preserving every exact protocol guarantee and failure result.
Source filenames below are in Sources/SecureToolKitCore, test filenames are
in Tests/SecureToolKitTesting, and checker filenames are in Scripts.
| Protocol concept | Current Swift type or namespace | Source filename | Relevant test filenames | Structural checker filename |
|---|---|---|---|---|
| Foundational identifiers and raw Proposal | ProposalID, SubjectID, TenantID, ToolProposal |
Sources/SecureToolKitCore/Identifiers.swift; Proposals.swift |
Phase1ValueTests.swift |
check_phase1_structure.py |
| Tool and Registry identifiers | ToolID, ToolVersion, Snapshot/Definition IDs |
ToolRegistryIdentifiers.swift |
ToolIdentifierValidationTests.swift |
check_phase2_structure.py |
| Registry and Tool Definition | ToolRegistryDraft, ToolRegistrySnapshot, ToolDefinition, ToolDefinitionReference |
ToolRegistry.swift; ToolDefinitions.swift; ToolRegistryValidation.swift |
ToolRegistryPublicationTests.swift; ToolRegistryLookupLifecycleTests.swift; ToolRegistryConcurrencyTests.swift |
check_phase2_structure.py |
| Schema and typed values | SchemaDefinition, ObjectSchema, FieldKind, StructuredObject |
SchemaModel.swift; SchemaErrors.swift |
SchemaModelTests.swift; SchemaValidationTests.swift; SchemaLimitsAndStringTests.swift |
check_phase3_structure.py |
| Canonicalization and Canonical Request | SchemaValidator, CanonicalRequest, CanonicalizationVersion |
CanonicalRequest.swift; SchemaModel.swift |
CanonicalRequestTests.swift; SchemaValidationTests.swift |
check_phase3_structure.py |
| Proposal Assessment | ProposalAssessmentClaim, ProposalAssessmentReference, validator |
ProposalAssessment.swift |
SchemaValidationTests.swift; EvaluationInputTests.swift; RC02SecurityRemediationTests.swift |
check_phase3_structure.py; check_phase4_structure.py |
| Host Capability Boundary | HostCapabilityBoundary |
HostCapabilityBoundary.swift |
HostAttestationTests.swift; RC02SecurityRemediationTests.swift; authorization tests |
check_phase4_structure.py; check_phase6_structure.py |
| Host and Role Authorities | HostAuthority, HostAuthorityScope, HostAttestationRole, validators |
HostAttestations.swift |
HostAttestationTests.swift; RC02SecurityRemediationTests.swift |
check_phase4_structure.py |
| Intent and Security Context | UserIntentEnvelope, SecurityContext, validators |
AuthenticatedContext.swift |
IntentSecurityContextTests.swift; EvaluationInputTests.swift |
check_phase4_structure.py |
| Provenance | ValidatedProvenanceSet, ProvenanceValidator |
Phase4Lineage.swift; Phase4Identifiers.swift |
ProvenanceInfluenceTests.swift; PolicyConditionLineageTests.swift |
check_phase4_structure.py; check_phase5_structure.py |
| Influence | ValidatedInfluenceSet, InfluenceValidator |
Phase4Lineage.swift; Phase4Identifiers.swift |
ProvenanceInfluenceTests.swift; PolicyConditionLineageTests.swift |
check_phase4_structure.py; check_phase5_structure.py |
| Evaluation Input | EvaluationInput, EvaluationInputValidator |
EvaluationInput.swift |
EvaluationInputTests.swift; RC02SecurityRemediationTests.swift |
check_phase4_structure.py |
| Policy Snapshot | PolicyDraft, PolicySnapshot, PolicyDefinition, PolicyRule |
PolicySnapshot.swift; PolicyModel.swift; PolicyIdentifiers.swift |
PolicyPublicationTests.swift; PolicyLimitsAndTimeTests.swift |
check_phase5_structure.py |
| Policy evaluator | PolicyEvaluator |
PolicyEvaluation.swift |
PolicyPredicateTests.swift; PolicyDecisionTests.swift; PolicyConditionLineageTests.swift |
check_phase5_structure.py |
| Policy Decision | PolicyDecision, PolicyDecisionBinding |
PolicyDecisions.swift |
PolicyDecisionTests.swift; RC02SecurityRemediationTests.swift |
check_phase5_structure.py |
| Authorization issuer | AuthorizationIssuer |
AuthorizationArtifacts.swift |
AuthorizationIssuanceTests.swift; AuthorizationScopeLifetimeTests.swift; AuthorizationLifetimeErrataTests.swift |
check_phase6_structure.py |
| Authorization artifact | Authorization, AuthorizationBinding, identifiers |
AuthorizationArtifacts.swift; AuthorizationModel.swift; AuthorizationIdentifiers.swift |
AuthorizationContractTests.swift; AuthorizationIdentifierTests.swift |
check_phase6_structure.py |
| Lifetime and freshness | AuthorizationLifetime, AuthorizationFreshness |
AuthorizationModel.swift; AuthorizationArtifacts.swift |
AuthorizationScopeLifetimeTests.swift; AuthorizationLifetimeErrataTests.swift |
check_phase6_structure.py |
| Replay Identity | AuthorizationReplayID, AuthorizationReplayBinding, AuthorizationReplayScope |
AuthorizationIdentifiers.swift; AuthorizationModel.swift |
AuthorizationContractTests.swift; AuthorizationValidationTests.swift |
check_phase6_structure.py |
| Consumption Binding | AuthorizationConsumptionBinding, AuthorizationConsumptionContract |
AuthorizationModel.swift |
AuthorizationContractTests.swift; RC02SecurityRemediationTests.swift |
check_phase6_structure.py |
| Validation Context | AuthorizationValidationContext |
AuthorizationValidation.swift |
AuthorizationValidationTests.swift; AuthorizationLifetimeErrataTests.swift |
check_phase6_structure.py |
| Validator and Validation result | AuthorizationValidator, AuthorizationValidationResult, AuthorizationReference |
AuthorizationValidation.swift |
AuthorizationValidationTests.swift; AuthorizationLifetimeErrataTests.swift; RC02SecurityRemediationTests.swift |
check_phase6_structure.py |
The module containing these files is SecureToolKitCore. Test files are under
Tests/SecureToolKitTesting; checker files are under Scripts.
This section is non-normative history and establishes no protocol requirement.
Phases 0–6, RC0.1, RC0.2, and the issuedAt errata produced the semantic
baseline summarized by this document. The Phase 1–6 architecture received an
architectural GO and a production NO-GO; Phase 7 has not begun.
Tag objects, commit hashes, platform results, test counts, the historical
RC0_FINAL defect, the RC0_FINAL_1 annotation claim, and the unresolved macOS
evidence discrepancy are recorded separately in
RC0_FINAL_1 Release Evidence. Release
evidence is state-specific and does not qualify or alter protocol semantics.
This section is a non-normative semantic status summary. Phase 1–6 protocol
semantics are complete at the implementation baseline tagged RC0_FINAL_1.
Swift is the reference implementation; it does not define the protocol.
The Phase 1–6 architecture is GO. Production deployment is NO-GO. Phase 7 has not started, and every deferred production blocker in Section 41 remains mandatory.
Authorization remains controlled structural evidence, not execution. Execution remains Host-owned and outside SecureToolKit. Validation remains pure and non-consuming. Atomic single-use Consumption remains mandatory before every protected side effect and is not implemented by Phase 1–6.
This section is normative. It transcribes the frozen canonicalization-v1
encoder; it does not create a new format. Version 1 is frozen. All octets are
shown in hexadecimal. Multi-octet unsigned integers use network byte order
(most-significant octet first). U16, U32, and U64 are unsigned integers of
exactly 2, 4, and 8 octets. ASCII(n) is exactly n ASCII octets.
| Primitive | Octet grammar | Constraint |
|---|---|---|
| Short string | U16(n) ASCII(n) |
Used for top-level identities and object field names; n is the exact byte count |
| String | U32(n) ASCII(n) |
Used for string, Resource, and enumeration values; n is the exact byte count |
| Signed integer | U64(bits) |
Exact signed 64-bit two's-complement bit pattern |
| Unsigned integer | U64(value) |
Exact unsigned 64-bit magnitude |
| Count | U16 for objects; U32 for arrays |
Exact following member count |
Lengths and counts include only the following content, not their own prefix, type tag, or enclosing value. No Unicode normalization, case folding, trimming, locale conversion, semantic normalization, or numeric text parsing occurs.
The envelope MUST contain every row exactly once and in this order:
| Order | Tag or marker | Content |
|---|---|---|
| 1 | 53 54 4B 43 52 51 00 |
Exact seven-octet marker: ASCII STKCRQ followed by 00 |
| 2 | none | Canonicalization version as U16; v1 is 00 01 |
| 3 | 01 |
Registry Snapshot identity as a short string |
| 4 | 02 |
Registry Snapshot generation as U64 |
| 5 | 03 |
Tool Identifier as a short string |
| 6 | 04 |
Tool Version generation as U64 |
| 7 | 05 |
Tool Definition identity as a short string |
| 8 | 06 |
Schema identity as a short string |
| 9 | 07 |
Schema version as U16; v1 is 00 01 |
| 10 | 08 |
One root value; Schema v1 requires an object value |
No field may be omitted, repeated, reordered, or followed by trailing octets. Proposal Assessment and the other complete structural bindings listed in Section 11 are deliberately outside these bytes.
| Value | Tag | Content after tag |
|---|---|---|
| String | 10 |
String encoding |
| Boolean false | 11 |
No content |
| Boolean true | 12 |
No content |
| Signed integer | 13 |
Signed integer encoding |
| Unsigned integer | 14 |
Unsigned integer encoding |
| Enumeration | 15 |
String encoding of the exact accepted case token |
| Array | 16 |
U32(count) followed by exactly count recursively encoded values |
| Object | 17 |
U16(count) followed by exactly count pairs of short field name and recursively encoded value |
| Resource identifier | 18 |
String encoding of the exact Resource identifier |
There are no reserved v1 value tags. Every other tag is unknown and MUST reject. Boolean values use distinct tags and have no Boolean payload octet.
Object members MUST be emitted in the exact Schema field order defined in Section 50, including only present fields. Duplicate object occurrences, unknown fields, and missing required fields have already rejected before encoding. Arrays preserve input order and duplicate array elements. Nested arrays and objects recursively use the same value grammar.
An empty string is 10 00 00 00 00; an empty array is
16 00 00 00 00; and an empty object is 17 00 00. Optional absence emits no
field-name/value pair. It is not encoded as null or an empty value. Null has no
tag and always rejects.
Canonical size is the sum of every marker, tag, length/count prefix, identity octet, field-name octet, and recursively encoded value octet in the complete envelope. The maximum is 65,536 octets inclusive. Before appending each segment, an encoder MUST verify that the resulting total will not exceed that maximum. It MUST reject rather than truncate, partially return, or wrap arithmetic.
Unknown marker, version, field tag, value tag, malformed or unrepresentable length/count, count/content mismatch, invalid Schema value, wrong field order, trailing data, or excessive total size MUST NOT be produced by a conforming encoder. The frozen implementation exposes no byte decoder. A future component claiming to accept canonicalization-v1 bytes MUST reject those states; this rule does not introduce a decoder or portable Authorization format.
Canonicalization-v1 byte equality remains narrower than complete Canonical Request structural equality.
This section is normative unless a row is explicitly marked Reference. Tokens are exact, case-sensitive ASCII protocol spellings; no display-label or wire-format inference is intended. Unknown tokens reject. Adding a token to a closed v1 vocabulary requires a new applicable protocol version. A single-valued field cannot contain duplicates; collection duplicate behavior is stated below.
| Vocabulary | Exact tokens in deterministic token order | Collection duplicate rule and ordering meaning |
|---|---|---|
| Capability | communication.external, data.read, data.write, financial.transfer, resource.delete |
Capability sets are unique and ASCII-byte sorted; order is deterministic, not privilege rank |
| Tool lifecycle | active, deprecated, retired |
Single value; order supports lifecycle/policy normalization, not authority rank |
| Tool risk | low, moderate, high, critical |
Single value; deterministic policy-key order only |
| Tool side effect | readOnly, reversibleMutation, irreversibleMutation, externalCommunication, financial |
Single value; deterministic policy-key order only |
| Tool reversibility | notApplicable, reversible, compensatable, irreversible |
Single value; deterministic policy-key order only |
| Schema version | v1 (generation 1) |
Single closed version |
| Canonicalization version | v1 (generation 1) |
Single closed version |
| Schema field requirement | required, optional |
Single value |
| Schema value kind | string, resourceID, bool, signedInteger, unsignedInteger, enumeration, array, object |
Single declared kind; arrays/objects recursively bind a child Schema |
| Untrusted Proposal trust class | unknown, untrusted |
Single model-controlled descriptive value; never a trust upgrade |
| Untrusted Proposal provenance source | unknown, model, userInput, retrievedContent, toolOutput |
Single model-controlled descriptive value; does not become validated Phase 4 Provenance |
| Authentication assurance | unknown, unauthenticated, singleFactor, multiFactor, phishingResistant, hardwareBound |
Semantically unordered; set operands are unique and normalized in this listed order |
| Authentication method | unknown, knowledgeFactor, possessionFactor, inherenceFactor, federated, hardwareAuthenticator |
Method collections are unique and normalized in this listed order |
| Session binding | session(identifier), sessionIndependent |
Mutually exclusive states; session independence is not wildcard scope |
| Intent target | exactRequest, boundedTool |
Mutually exclusive parameterized states |
| Intent version | v1 (generation 1) |
Single closed version |
| Security Context version | v1 (generation 1) |
Single closed version |
| Evaluation Input version | v1 (generation 1) |
Single closed version |
| Provenance coverage | unknown, represented |
Single value; deterministic policy-key order only |
| Provenance source | unknown, directUserInput, retrievedWebContent, emailContent, documentContent, toolOutput, modelOutput, applicationState, hostGeneratedValue, importedExternalData |
Single value; listed order is the deterministic source order |
| Provenance verification | unverified, hostVerified |
Single controlled status |
| Provenance trust | unknown, untrusted, hostVerified |
Single value; set operands are unique and normalized in this listed order |
| Provenance transformation | extracted, filtered, redacted, summarized, translated, generatedByModel, combined |
Transformation lists preserve supplied order and MAY repeat; listed order is used only in deterministic predicate keys |
| Influence completeness | unknown, partial, complete |
Single boundary-local value; raw complete additionally requires exact attestation identity |
| Influence kind | unknown, userPrompt, systemInstruction, retrievedContent, email, document, toolOutput, modelOutput, memory, applicationState, externalEvent |
Single value; listed order is the deterministic predicate-key order |
| Host-attestation role | authenticationAuthority, intentCaptureAuthority, provenanceAuthority, influenceCollector, delegationAuthority, policyAdministrationAuthority |
Role sets are unique and normalized in this listed order |
| Host-attestation fact | securityContext, userIntent, provenance, influenceCollection, delegation |
Single parameterized fact; each maps to its exact permitted role |
| Vocabulary | Exact tokens and order | Duplicate rule |
|---|---|---|
| Policy lifecycle | active, deprecated, retired |
Single value |
| Policy effect/outcome | deny, requireConfirmation, allow |
Single value; this order is also decision precedence |
| Condition kind | all, any, predicate |
Compound children are nonempty, unique, and normalized; predicates are single values |
| Obligation kind | requireConfirmation, maximumEvaluationAgeSeconds(seconds), requireCompleteInfluenceBoundary(identifier), requireSingleUseAuthorization, requireAuditEvent |
Obligation collections are unique and use Section 50 order |
The exact closed predicate tokens are:
| Order | Predicate token and operand |
|---|---|
| 00 | exactToolID(identifier) |
| 01 | exactToolVersion(generation) |
| 02 | exactDefinitionID(identifier) |
| 03 | exactRegistrySnapshot(identifier, generation) |
| 04 | lifecycleIs(value) |
| 05 | riskIs(value) |
| 06 | sideEffectIs(value) |
| 07 | reversibilityIs(value) |
| 08 | exactSubject(identifier) |
| 09 | exactTenant(identifier) |
| 10 | exactSession(identifier) |
| 11 | sessionIsIndependent |
| 12 | delegationPresent |
| 13 | exactDelegationID(identifier) |
| 14 | assuranceIsOneOf(values) |
| 15 | authenticationMethodIncludes(value) |
| 16 | authenticationMethodsIncludeAll(values) |
| 17 | requestedCapabilitiesSubsetOf(values) |
| 18 | requestedCapabilitiesInclude(values) |
| 19 | intendedCapabilitiesInclude(values) |
| 20 | exactRequestedResource(identifier) |
| 21 | requestedResourcesSubsetOf(values) |
| 22 | requestedResourcesInclude(values) |
| 23 | provenanceCoverageIs(value) |
| 24 | provenanceContainsSource(value) |
| 25 | provenanceTrustIsOneOf(values) |
| 26 | provenanceContainsTransformation(value) |
| 27 | provenanceContainsNoSemanticTransformation |
| 28 | influenceBoundaryCompletenessIs(identifier, value) |
| 29 | allInfluenceBoundariesComplete |
| 30 | influenceContainsKind(value) |
| 31 | influenceContainsNoKind(value) |
| 32 | exactInfluenceBoundary(identifier) |
| 33 | maximumInfluenceCount(count) |
| 34 | evaluationTimeWithin(window) |
| 35 | renewalGenerationIs(generation) |
| 36 | maximumIntentAge(seconds) |
| 37 | maximumContextAge(seconds) |
Collection-valued predicate operands are nonempty and unique. Their bounds retain the Protocol/Reference classification in Section 39.
Policy stable reasons use this exact deterministic order:
policyMissing, policyUnknown, policyRetired, policyInvalid,
noAllowRuleMatched, denyRuleMatched, confirmationRuleMatched,
allowRuleMatched, conditionIndeterminate, unsupportedInputVersion,
toolMismatch, lifecycleDenied, capabilityNotPermitted,
resourceNotPermitted, assuranceInsufficient,
authenticationMethodMissing, provenanceInsufficient,
influenceIncomplete, influenceKindDenied, tenantMismatch,
subjectMismatch, sessionMismatch, delegationRequired, evaluationTooOld,
obligationUnsatisfiedAtPolicyStage, policyLimitExceeded
Reason collections are deduplicated, then sorted by that order. Unknown reason tokens reject and cannot be used as free text.
| Vocabulary | Exact tokens | Status |
|---|---|---|
| Policy Decision version | v1 (generation 1) |
Protocol |
| Authorization representation version | v1 (generation 1) |
Protocol |
| Consumption contract | atomicSingleUseRequired |
Protocol; single mandatory value |
| Validation outcome | successful, failed |
Protocol state names, not serialized values |
Swift error enums and safe-field enums—including Registry, Schema, Phase 4, Policy publication/evaluation, Authorization, and Validation error cases—are Reference API vocabularies. The protocol normatively requires the failure semantics and privacy properties in Sections 33 and 37, not identical language-level enum names. No Authorization wire representation is defined.
This section is normative except where explicitly marked Reference. All grammars operate on ASCII octets. Values are case-sensitive. No value is trimmed, case-folded, Unicode-normalized, repaired, aliased, or whitespace normalized. Any invalid or empty value rejects the transition that requires the identifier.
lower-alnum is one of a–z or 0–9. lower-token(N) is either one
lower-alnum, or a 2-to-N-octet value whose first and last octets are
lower-alnum and whose interior octets are lower-alnum or -. Consecutive
interior hyphens are permitted. A dot is not permitted unless a grammar below
explicitly permits it.
| Family | Exact grammar and bound | Duplicate and ordering rule |
|---|---|---|
| Tool Identifier | 2–8 dot-separated lower-token(32) segments; 128 octets total |
Exact identity; duplicates reject Registry publication; ASCII segment sequence comparison |
| Tool or Registry Snapshot version text | Canonical decimal integer 1–18446744073709551615; first digit 1–9, remaining digits 0–9, at most 20 octets |
Numeric ordering; leading zero, sign, whitespace, decimal point, suffix, or overflow rejects |
| Registry Snapshot identity | lower-token(64) |
Exact identity; ASCII-byte ordering where ordered |
| Tool Definition identity | lower-token(64) |
Unique within Snapshot; ASCII-byte tiebreak ordering |
| Schema identity | lower-token(64) |
Exact identity |
| Field name or enumeration case | lower-token(64) |
Schema-local duplicates reject; ASCII-byte ordering |
| Capability | One exact token from Section 48 | Set duplicates reject; ASCII-byte ordering |
| Resource | lower-token(64) after reviewed resourceID Schema validation |
Set duplicates collapse only during deterministic Resource derivation; scope collections require unique values and ASCII-byte order |
| Phase 4 controlled identity | lower-token(64) |
Exact identity; duplicates reject where a collection requires uniqueness |
| Policy identity | lower-token(64) |
Exact identity; ASCII-byte ordering |
| Policy generation text | Canonical positive unsigned 64-bit decimal, with no leading zero or sign | Numeric ordering |
| Documentation reference | 1–64 octets; first/last lower-alnum; interior lower-alnum, -, or . |
Exact descriptive identity; consecutive interior dots or hyphens are permitted |
| Tool display title | 1–80 printable ASCII octets 20–7E; first/last MUST NOT be space |
Non-authoritative; exact value, no ordering semantics |
| Tool safe summary | 1–240 printable ASCII octets 20–7E; first/last MUST NOT be space |
Non-authoritative; exact value, no ordering semantics |
| Intent display text | Absent or 1–160 printable ASCII octets 20–7E |
Non-authoritative; leading/trailing spaces are preserved |
| Authorization, replay, or Consumption identity | Swift Reference: lower-token(64) |
Exact structural identity and ASCII-byte ordering in Swift; 64 is not a universal Protocol maximum |
The Phase 4 controlled-identity grammar applies to Context, Host Authority, Host attestation, Proposal Assessment, the Proposal identity retained by that assessment, Intent, subject, tenant, session, delegation, Provenance record, Influence node, Influence collection boundary, and external evidence-reference identities. Raw Phase 1 wrapper values are untrusted; the applicable controlled Phase 4 transition MUST validate this grammar before they contribute to a controlled artifact.
The Policy identity grammar applies to Policy Snapshot, Policy Definition, Policy Rule, and Decision identities. Proposal Assessment expected Provenance and Influence collections contain unique identities sorted as specified in Section 50.
Host Capability Boundary has no textual identifier grammar. Its protocol identity is opaque process-local domain identity; descriptive equality cannot substitute for possession of the exact retained boundary.
Another language implementation MAY use a different finite deterministic Authorization/replay/Consumption identifier bound under the Reference rule in Section 39. It MUST still preserve exact identity equality, disclose the difference for interoperability, and reject values outside its documented bound. No identifier proves authenticity, randomness, uniqueness, or authority.
This section is normative. ASCII-byte order means unsigned lexicographic comparison of the already validated ASCII octets. Numeric order compares the unsigned generation value, not decimal text. Ordering never performs case folding or locale comparison.
| Value or collection | Exact order | Semantic effect and duplicates |
|---|---|---|
| Registry Tool Definitions | Tool Identifier ASCII order, then Tool Version numeric order, then Tool Definition identity ASCII order | Determines immutable Snapshot output; duplicate resolution/definition identities reject |
| Schema fields | Field-name ASCII order | Determines semantic object field order and canonical bytes; duplicate names reject |
| Enumeration declarations | Case-token ASCII order | Deterministic Schema content; duplicate cases reject |
| Arrays | Original validated input order | Order and duplicates are semantically significant |
| Resource derivation/set | Unique Resource identifiers in ASCII order | Set equality is semantic; repeated array occurrences do not add authority |
| Proposal Assessment | Provenance identities ASCII-sorted; Influence collection identities ASCII-sorted | Both collections are unique; order supports exact continuity |
| Provenance records | Provenance identity ASCII order | Duplicate record identities reject |
| Provenance transformations | Original declared order | Order is semantic lineage; repetition is retained |
| Influence records | Influence identity ASCII order | Duplicate record identities reject |
| Influence parent IDs/edges | Parent IDs ASCII-sorted within each child; children in Influence identity order | Duplicate/self edges reject; order is deterministic graph representation |
| Influence collections | Collection-boundary identity ASCII order | Duplicate boundary identities reject |
| Host roles | Section 48 role order | Role set is unique; order is deterministic only |
| Host attestations/Role Authorities | Exact attestation or authority identity ASCII order | Duplicate/conflicting issuers reject as specified |
| Policy Definitions | Policy identity ASCII order, then Policy generation numeric order | Determines Snapshot output; duplicates reject |
| Policy Rules | Rule identity ASCII order | Duplicate rule identities reject |
| Capability/Resource constraints | Exact token/identifier ASCII order | Collections are unique; order is deterministic set representation |
| Matched rules | Rule identity ASCII order | Unique deterministic Decision evidence |
| Reasons | Section 48 reason order | Deduplicated before ordering |
| Obligations | ASCII order of key 0, 1:<decimal seconds>, 2:<boundary identity>, 3, or 4, corresponding to the Section 48 obligation order |
Duplicate complete obligations reject; ordering is deterministic and the decimal comparison is lexical within kind 1 |
| Authorization bindings | Exact typed structural field equality | No portable byte ordering is defined; declaration or memory layout has no protocol meaning |
Compound all and any children are semantically unordered, MUST be nonempty
and unique, and are normalized by ASCII comparison of this recursive key:
all(children) -> "0[" + comma-joined child keys + "]"
any(children) -> "1[" + comma-joined child keys + "]"
predicate(value) -> "2:" + predicate key
Predicate keys begin with the two-decimal-digit order 00 through 37 in
Section 48, followed where applicable by : and the exact normalized operand.
Identifier operands use exact ASCII text; generations and counts use canonical
unsigned decimal text; enum operands use their Section 48 order number; list
operands are normalized first and comma-joined. Predicate 03 joins Snapshot
identity and generation with :; predicate 28 joins boundary identity and
completeness order with :; predicate 34 joins issuedAt, notBefore, and
expiresAt epoch seconds with :. This key is an in-memory normalization rule,
not a portable Policy serialization.
This section is normative. Spaces in hexadecimal are presentation separators and are not octets. The value-fragment vectors exercise the recursive grammar from Section 47; only the complete vector is a complete Canonical Request.
| Typed input | Exact hexadecimal octets | Count | Segments |
|---|---|---|---|
| Empty string | 10 00 00 00 00 |
5 | tag 10; U32 length 0 |
String Az~ |
10 00 00 00 03 41 7A 7E |
8 | tag; U32 length 3; ASCII payload |
| Boolean false | 11 |
1 | false tag; no payload |
| Boolean true | 12 |
1 | true tag; no payload |
| Signed zero | 13 00 00 00 00 00 00 00 00 |
9 | tag; signed 64-bit zero bits |
| Signed negative one | 13 FF FF FF FF FF FF FF FF |
9 | tag; two's-complement −1 |
| Signed minimum | 13 80 00 00 00 00 00 00 00 |
9 | tag; −2^63 bits |
| Signed maximum | 13 7F FF FF FF FF FF FF FF |
9 | tag; 2^63−1 bits |
| Unsigned zero | 14 00 00 00 00 00 00 00 00 |
9 | tag; U64 zero |
| Unsigned maximum | 14 FF FF FF FF FF FF FF FF |
9 | tag; 2^64−1 |
Enumeration ready |
15 00 00 00 05 72 65 61 64 79 |
10 | tag; U32 length 5; exact case token |
Resource acct-1 |
18 00 00 00 06 61 63 63 74 2D 31 |
11 | tag; U32 length 6; exact identifier |
| Empty array | 16 00 00 00 00 |
5 | tag; U32 count 0 |
Ordered array [false, true] |
16 00 00 00 02 11 12 |
7 | tag; U32 count 2; values in order |
| Empty object | 17 00 00 |
3 | tag; U16 count 0 |
Object {a: UInt64(0), z: "x"} |
17 00 02 00 01 61 14 00 00 00 00 00 00 00 00 00 01 7A 10 00 00 00 01 78 |
24 | object count 2; short name a; UInt64 zero; short name z; one-octet string |
Object {items: [Int64(-1), {}]} |
17 00 01 00 05 69 74 65 6D 73 16 00 00 00 02 13 FF FF FF FF FF FF FF FF 17 00 00 |
27 | object/name; array count 2; signed −1; nested empty object |
The two-field object is canonical only for a Schema whose field order is a,
then z. Reversing the input occurrence order produces the same listed bytes.
The accepted empty-root-object fixture uses Registry Snapshot
primary-registry generation 1, Tool payments.submit version 1, Tool
Definition payments-submit-1, Schema empty version 1, and canonicalization
version 1. Its exact 99 octets are:
53 54 4B 43 52 51 00 00 01
01 00 10 70 72 69 6D 61 72 79 2D 72 65 67 69 73 74 72 79
02 00 00 00 00 00 00 00 01
03 00 0F 70 61 79 6D 65 6E 74 73 2E 73 75 62 6D 69 74
04 00 00 00 00 00 00 00 01
05 00 11 70 61 79 6D 65 6E 74 73 2D 73 75 62 6D 69 74 2D 31
06 00 05 65 6D 70 74 79
07 00 01
08 17 00 00
| Segment | Count |
|---|---|
| Marker and canonicalization version | 9 |
Tag 01 plus 16-octet Snapshot identity |
19 |
Tag 02 plus Snapshot generation |
9 |
Tag 03 plus 15-octet Tool Identifier |
18 |
Tag 04 plus Tool Version |
9 |
Tag 05 plus 17-octet Definition identity |
20 |
Tag 06 plus 5-octet Schema identity |
8 |
Tag 07 plus Schema version |
3 |
Tag 08 plus empty object |
4 |
| Total | 99 |
The frozen implementation is encoder-only. These vectors specify bytes a conforming encoder MUST NOT produce. A future decoder claiming v1 compatibility MUST reject them; no decoder API is defined here.
| Invalid state | Prohibited hexadecimal or construction | Required result |
|---|---|---|
| Unknown marker | Complete vector with first octet 52 instead of 53 |
Reject marker |
| Unknown canonicalization version | Marker followed by 00 02 |
Reject version |
| Unknown or misplaced envelope field tag | Complete envelope with 09 where ordered tag 01 is required |
Reject field tag/order |
| Unknown value tag | Standalone value fragment 19 |
Reject tag |
| Truncated string | 10 00 00 00 02 41 |
Reject: declared length 2, one payload octet |
| Incorrect array count | 16 00 00 00 02 11 |
Reject: declared count 2, one value |
| Invalid Boolean payload | Standalone fragment 11 00 |
Reject trailing octet; Boolean has no payload |
| Non-network byte order | Marker followed by 01 00 for v1 |
Reject unsupported version; v1 is 00 01 |
| Reordered object fields | The Section 51.1 two-field object with z encoded before a |
Reject/nonconforming encoder output for that Schema |
| Oversized output | Any construction whose next append would make the complete request 65,537 octets | Reject before append; no truncation or partial bytes |
| Trailing bytes | Complete 99-octet vector followed by 00 |
Reject trailing data in any future v1 decoder |
| Null | Any attempted null value | Reject before encoding; no null tag exists |
All positive hexadecimal values in this section are mechanically reproducible from the frozen grammar and the accepted complete fixture. Unknown values or extensions are not inferred into version 1.