Skip to content

PHASE_4_DECISIONS.md

Latest commit

 

History

History
284 lines (223 loc) · 13.2 KB

PHASE_4_DECISIONS.md

File metadata and controls

284 lines (223 loc) · 13.2 KB
Raw

Phase 4 Decisions

RC0.1 host capability boundary

Authenticated bootstrap retains one opaque HostCapabilityBoundary and publishes HostAuthority with immutable capability/resource ceilings. Every applicable attestation in an EvaluationInput binds that exact authority. Requested resources equal the canonical argument-derived set.

Phase 4 implements deterministic validation and exact binding of authenticated intent, security context, provenance, influence, host attestations, and one complete EvaluationInput. It does not implement policy evaluation, allow/deny outcomes, capability grants, authorization, confirmation, execution, parsing, networking, persistence, hashing, cryptography, or a trusted clock.

Construction and trust boundary

Raw claims are immutable public values because hosts need to transport explicit facts into the library. HostAuthorityClaim, HostAttestationClaim, SecurityContextClaim, UserIntentClaim, ProvenanceClaim, InfluenceClaim, and InfluenceCollectionClaim are not trusted by construction.

Validated or trusted-boundary values have no public initializer:

  • HostAuthority
  • ValidatedHostAttestation
  • SecurityContext
  • UserIntentEnvelope
  • ValidatedProvenanceRecord and ValidatedProvenanceSet
  • ValidatedInfluenceRecord, ValidatedInfluenceCollection, and ValidatedInfluenceSet
  • EvaluationInput

They arise only from narrow deterministic validators. This is a structural host-integration boundary, not cryptographic caller authentication. Swift cannot distinguish a model-controlled caller from authenticated host code by itself. The host must expose authority and attestation validation only through an authenticated integration path and must never route model fields into it.

Identity and versioning

Phase 4 adds nominal identifiers for contexts, host authorities, attestations, provenance, influences, collection boundaries, delegations, and privacy-safe evidence references. They accept exact 1...64 byte lowercase ASCII alphanumeric/hyphen syntax with alphanumeric ends. They never trim, normalize, repair, alias, or generate values.

IntentVersion.v1, SecurityContextVersion.v1, and EvaluationInputVersion.v1 are independent closed versions. Unknown versions reject. Existing IntentID, SubjectID, TenantID, SessionID, and ResourceID remain publicly constructible Phase 1 identifiers, but Phase 4 validators apply the same bounded restricted syntax before accepting them into validated facts.

Explicit time and freshness

EpochSeconds is an explicitly supplied unsigned Unix-epoch second bounded to 0...4_102_444_800 (2100-01-01 UTC). It performs no formatting and reads no clock. ValidityWindow requires:

issuedAt <= notBefore < expiresAt

At evaluation, notBefore is inclusive and expiresAt is exclusive. Every validator receives evaluationTime explicitly. Intent, context, and every applicable attestation are rechecked when constructing EvaluationInput. Phase 4 does not determine whether supplied time is trustworthy; trusted-time infrastructure, rollback handling, and maximum production lifetimes remain Phase 6 decisions.

Host authority and attestations

An authority has one or more unique roles from this closed set:

  • authenticationAuthority
  • intentCaptureAuthority
  • provenanceAuthority
  • influenceCollector
  • delegationAuthority

Each attestation binds one ID, issuer, single role, subject, tenant, exact session state, validity window, and exactly one structural fact. Context facts commit to version, assurance, ordered methods, delegation, and validity; intent facts commit to version, complete structured scope, validity, and renewal; provenance facts commit to source, evidence reference, and transformations; and collector facts commit to a boundary plus its complete sorted influence-ID set. The fact-to-role mapping is fixed. A role configured for the authority still cannot attest a different fact category. Wrong issuer, role, value, scope, or freshness rejects, including substitution of a changed value under the same ID.

Attestations are structured non-cryptographic evidence. The optional revocationReferenceID is a privacy-safe pointer for a future host protocol; Phase 4 performs no revocation lookup and claims no trust store, signature, key rotation, or remote verification.

Security context

SecurityContextClaim binds an exact context ID/version, subject, tenant, session state, assurance category, authentication-method classifications, optional delegation ID, validity, and authentication attestation reference.

Assurance is closed and deliberately unordered: unknown, unauthenticated, single factor, multi-factor, phishing resistant, or hardware bound. These are host-attested classifications; SecureToolKit does not verify platform behavior or infer assurance from methods. Authentication methods are closed descriptive categories, unique, bounded, and deterministically ordered. No credential, secret, token, or raw identity-provider assertion is stored.

A delegation is represented only by an exact DelegationID. If present, a fresh matching delegation-role attestation with the same subject, tenant, and session is mandatory. Delegated capabilities and entitlement semantics remain future policy/host data design; Phase 4 does not infer them.

SecuritySessionBinding is either one exact SessionID or explicit sessionIndependent. Session independence is not a wildcard: intent, context, attestations, provenance, influences, and evaluation must all carry the same exact state.

Structured authenticated intent

UserIntentEnvelope is controlled output from a raw UserIntentClaim and a matching intentCaptureAuthority attestation. Authoritative intent contains no semantic text matcher. Optional printable-ASCII display text is bounded to 160 bytes and never defines scope.

Phase 4 supports two targets:

  1. exactRequest(CanonicalRequest) for an exact Phase 3 request.
  2. boundedTool(ToolDefinitionReference) for one exact registry snapshot and immutable tool definition.

It does not support a broader session task, any-tool target, wildcard, all resources, all capabilities, semantic similarity, classifier, or permissive default. Broader task intent remains deferred because its safe constraint model is not yet specified.

Every intent has nonempty, unique, sorted, bounded intended capabilities and bounded exact resources. Resources may be exactly empty for a genuinely resource-free canonical request; empty is never wildcard. Intended capabilities must be within the registered definition maximum. This is validation of an upper bound, not final policy intersection or a grant. Resources are exact scaffolding identifiers, not predicates or proof of access.

Intent carries an explicit positive renewal generation. Renewal never occurs implicitly; EvaluationInput must supply the exact expected generation. A new generation requires newly captured and attested intent.

Provenance and trust upgrades

ProvenanceClaim contains an exact ID, closed source class, privacy-safe evidence reference, ordered transformations, and optional attestation reference. It contains no raw content and no trusted flag.

Missing provenance yields an empty ValidatedProvenanceSet with .unknown coverage. Any known source without matching evidence remains .untrusted; unknown source remains .unknown. This includes direct user input, host-generated values, application state, local/imported data, and registered tool output. Transport or registration never upgrades content.

A fresh exact-scope provenanceAuthority attestation may produce .hostVerified. That state means the host attested the provenance record and allowed transformation chain; it does not mean arbitrary referenced content is correct, safe, or authoritative. No API converts the older public TrustClass shell or an untrusted claim directly into host-verified data.

Transformation order is preserved and bounded. Extracted, filtered, and redacted lineage may be host verified. Summarized, translated, model-generated, or combined lineage prevents Phase 4 trust upgrade. No trust propagates transitively and no semantic preservation is claimed.

Influence and completeness

Influence is separate from provenance. An InfluenceClaim identifies material, a system, or an event that may have shaped a proposal even when absent from canonical arguments. It stores an exact ID, closed kind, privacy-safe evidence reference, optional provenance ID, parent IDs, and collection-boundary ID. No raw prompt or document content is stored.

Parent relationships form a bounded directed acyclic structure. Duplicate IDs, duplicate/self parents, missing parents, cross-boundary parents, cycles, excess nodes, and excess edges reject. Records and parents are sorted by exact ID; the validation uses bounded iterative traversal.

Completeness is boundary-local:

  • unknown: no reliable coverage statement.
  • partial: some known influences are represented.
  • complete: a fresh exact-boundary influenceCollector attestation reports every influence visible inside that named boundary.

A raw .complete claim is untrusted and requires an attestation reference. It cannot become validated complete without matching collector evidence. Empty unknown and empty attested-complete collections remain unequal. Multiple collectors are retained as separate boundaries and never merged into global completeness. Missing collection declarations default to unknown for each referenced boundary.

EvaluationInput

EvaluationInputValidator returns one value or throws with no partial result. It requires and binds:

  • one exact CanonicalRequest and matching ToolDefinitionReference;
  • one UserIntentEnvelope and compatible SecurityContext;
  • one explicit requested capability/resource classification;
  • one exact-scope ValidatedProvenanceSet;
  • one exact-scope ValidatedInfluenceSet with separate boundaries;
  • all applicable validated attestations in deterministic unique order;
  • an explicit evaluation time, renewal generation, and input version.

Construction rejects canonical/tool, subject, tenant, session, renewal, freshness, attestation, capability, resource, provenance, or influence scope mismatch. Requested capabilities/resources must be subsets of explicit intent; capabilities must also remain within the definition maximum. This is not final capability intersection and does not establish resource entitlement. Phase 3 derives exact resources only from reviewed typed resourceID schema nodes; Phase 4 requires requested resources to equal that canonical-derived set.

RC0.2 assessment and role-authority composition

CanonicalRequest retains a controlled privacy-safe ProposalAssessmentReference. Provenance and influence validation retain the same reference, and complete input construction requires exact equality plus an independently supplied common boundary. Raw Phase 1 declarations never upgrade trust.

Distinct role-specific authorities may provide authentication, intent, provenance, influence, and delegation evidence. They must share the genuine boundary and one exact entitlement ceiling. Exact issuer-role binding, conflicting-scope rejection, and deterministic issuer ordering prevent authority union or role substitution. A monolithic all-role authority is only an explicit trusted-host profile.

EvaluationInput has no decision, allow/deny result, policy reference, authorization, confirmation, callback, executor, or side effect.

Deterministic limits

Resource Limit
Restricted identifier 64 bytes
Validated/applicable attestations 16
Authentication methods 8
Intended capabilities 8
Intended resources 16
Provenance records 64
Transformations per provenance record 8
Influence records 64
Influence edges 128
Collection boundaries 8
Non-authoritative intent display text 160 bytes
Explicit epoch second 4,102,444,800

Collections reject before unbounded traversal and are never truncated. Output ordering is exact ASCII identifier order. Transformation order remains security-significant lineage order.

Error model

Phase4Error exposes only a stable Phase4FailureReason, optional safe Phase4Field, and optional public limit. It contains no raw prompt, document, model output, secret, credential, personal data, or rejected display value. Failures are validation evidence, not policy denials.

Deliberately deferred

  • Phase 5: policy representation, policy snapshots, allow/deny/confirmation outcomes, final capability intersection, resource entitlement semantics, and policy use of assurance/provenance/completeness.
  • Phase 6: authorization artifacts, cryptographic commitments, trust stores, revocation, trusted time, expiry policy, idempotency, and atomic consumption.
  • Later phases: confirmation behavior, audit chaining, adapters, persistence, networking, platform identity integrations, and execution.

Phase 3 canonicalization version 1 and its fixed byte vector are unchanged.

Validation evidence

On 2026-07-15, the official swift:6.0-jammy image (Swift 6.0.3) successfully ran package description, build, the complete 170-test suite in normal and verbose modes, strict recursive formatter lint, and Phase 1–4 structural checks. The fixed Phase 3 canonical vector passed. This Linux validation does not claim macOS or other Apple-platform execution.