ADR-0018: Profiled Core Semantics Identity and Bounded Stage 1 Freeze

Status: accepted
Date: 2026-07-25

Context

The bounded Stage 1 audit found executable evidence for the Core schema, verifier, ANF interpreter, numeric/effect/store/closure/ownership semantics, Surface elaboration, differential parity, and deterministic artifact hashes.

One required identity was missing. semantic_hash(program) identifies a Core program, but Roadmap Stage 1 and the P1 structural certificate separately require an interpreter_semantics_hash. Reusing a program hash would conflate code with the semantics that execute it.

The identity must remain stable across hosts and append-only profiles. It must not change because Rust formatting, comments, filenames, or documentation layout changed.

Options considered

Option	Benefit	Cost
Reuse a program semantic hash	No new mechanism	Does not identify interpreter semantics
Hash Rust interpreter source	Easy to automate	Host implementation and comments become authority
Hash the Typed Core Markdown	Human-readable source	Formatting and documentation layout become semantic
One global manually chosen UUID	Small	Later profile additions perturb or obscure scope
Canonical per-profile semantics manifest	Stable, scoped, host-independent	Manifest versions require disciplined maintenance

Decision

Define Semantic Identity Encoding v1 with domain:

NAUX:core-n0:interpreter-semantics:v1\0

For a selected CoreProfile, canonical bytes contain:

identity domain;
Core schema name and version;
semantics-identity format version;
profile tag;
an ordered cumulative sequence of versioned semantic capability IDs.

The SHA-256 digest of those bytes is:

interpreter_semantics_hash(profile)

Capabilities are cumulative. Adding P1V6 allocates a new profile identity but does not change P1V0–P1V5 bytes or hashes. Changing the meaning of an existing capability requires a new identity domain/version or capability revision, an ADR, migration policy, and new vectors.

The manifest is encoded and hashed by the std-only Core nucleus. It does not read source files or documentation at runtime.

Stage 1 freeze

Once the identity implementation, locked vectors, audit matrix, and full gates are green:

bounded Stage 1 is accepted for profiles P1V0–P1V5;
the exact Stage 2 lighthouse semantic input is frozen to P1V0;
later append-only Core profiles remain allowed but do not silently widen P1 v0;
Stage 2 may begin with binding-time judgment and verification only;
no residualizer, P1, Projection Birth, or Nauxogenesis claim follows from this freeze.

The clean source-revision/tag action remains owner-controlled and is required before a reproducible public claim bundle.

These conditions are satisfied by the accepted bounded Stage 1 exit audit. The only newly opened scope is the B0 binding-time judgment and evidence verifier.

Capability identity versus proof

The manifest is a versioned identity, not a proof that the Rust seed implements it correctly. Acceptance also requires:

verified-only evaluation entry;
positive and negative semantic corpora;
Surface/Core differential evidence for admitted elaboration;
locked artifact vectors;
full formatting, lint, test, governance, shell, and link gates.

An implementation that disagrees with the contract is wrong even if it emits the expected identity hash.

Rationale

P1 provenance needs to distinguish static program, interpreter semantics, specializer, and policy hashes.
Per-profile identities keep the P1V0 lighthouse stable while Core evolves.
Capability revisions make semantic change explicit without treating Rust representation as canonical.
Canonical framing reuses the same host-independent discipline as Core artifact encoding.

Trade-offs

Capability IDs are curated rather than derived automatically from code.
A semantic implementation change can be dishonest if maintainers fail to revise the manifest; independent tests and review remain necessary.
The freeze covers bounded admitted profiles, not every future Core feature.
Stage 2 still has no binding-time analyzer, residualizer, or projection.

Consequences

Positive: Stage 2 certificates gain a stable, correctly scoped interpreter_semantics_hash, and P1V0 no longer drifts when later profiles are added.

Negative: semantic revisions now require coordinated identity and migration work.

Mitigation: locked vectors and an explicit audit contract fail when identity bytes change.

Revisit trigger

Move from curated capability identities to proof-carrying semantic modules only when an independent formal kernel can compute or certify an equivalent identity without making host implementation bytes authoritative.