ADR-0019: B0 Request Trust Boundary and Policy Identity
Status: accepted
Date: 2026-07-25
Context
ADR-0002 defines the two-point binding-time judgment, and ADR-0018 freezes the P1V0 semantic input. Before inference exists, B0 needs a trust boundary that prevents an analyzer from silently changing the source artifact, interpreter semantics, entry classification, policy version, or resource budget.
The boundary must be deterministic, std-only, independently reproducible, and strictly narrower than a partial evaluator.
Options considered
| Option | Benefit | Cost |
|---|---|---|
| Pass ordinary analyzer arguments | Minimal code | No canonical provenance or forgery boundary |
| Reuse the future P1 certificate | One evidence format | Couples unfinished analysis to residualization and native fields |
| Hash only the source artifact | Small identity | Omits semantics, policy, manifest, and budgets |
| Canonical B0 policy and request envelopes | Explicit, reproducible, fail-closed | Adds versioned metadata and vector maintenance |
Decision
Introduce a B0-A request boundary with:
- the exact verified P1V0 source artifact hash;
- the locked P1V0
interpreter_semantics_hash; - an exact entry-parameter
Static/Dynamicmanifest; - a separately versioned and hashed B0 analysis policy;
- explicit node, call-edge, and fixed-point budgets;
- fixed implementation hard caps;
- a domain-separated canonical request encoding and hash.
Validation recomputes artifact validity, source hash, interpreter-semantics hash, policy hash, manifest arity, and budget legality. P1V1 and later profiles fail closed even when they are valid Core artifacts.
The policy identity declares the accepted target rules; it is not proof that inference or evidence verification exists.
Rationale
- Analyzer output cannot redefine its own semantic input.
- Budget increases become hash-visible and reviewable.
- Policy evolution does not perturb Core artifact or interpreter-semantics identities.
- B0 evidence can later bind to
request_hashwithout importing residual or native certificate fields.
Trade-offs
- Policy and request encodings add versioning work before inference.
- Curated policy capability IDs require disciplined revision.
- Fixed hard caps may reject a legitimate future workload.
- B0-A validates provenance but proves no node judgment.
These costs are accepted because fail-closed provenance is cheaper to establish before analyzer and certificate formats depend on unstable implicit inputs.
Consequences
Positive: B0-B inference receives only a verified, hash-bound request.
Negative: changing a hard cap, field order, policy capability, or tag requires a new version/domain or coordinated vector migration.
Mitigation: locked policy/source/request vectors and forged-field tests cover the complete envelope.
Revisit trigger
Revisit the hard caps or P1V0-only boundary only when executable B0 evidence shows a valid lighthouse case cannot fit, and record that change through a new ADR and versioned vectors.