Candidate Evidence Contract Decision Packet

Purpose

This Internal Knowledge packet gives Lee, the agent-orch contract owner, a bounded decision record for a declaration conflict. The human-readable candidate-evidence contract currently declares five checks and a JSON-tool allowlist, while the executable, model, and valid-fixture route currently declares three pinned journeys with exact -B pytest or smoke commands. The packet records those facts without selecting a canonical contract, changing an input, or treating any declaration as proof that a command ran.

The intended outcome is a human decision about which route, if any, should later be reconciled and who should own that migration, while every input remains unchanged. The first declaration is the human-readable five-check contract in docs/candidate-evidence-preflight-contract.md, whose companion route is described as JSON-tool based. The second is the three-journey executable, model, and fixture route in the candidate-evidence handoff manifest and model. These are current expectations only: no declaration, model, fixture, or allowlist entry is execution proof or approval.

The deterministic preflight check exposes the practical form of this conflict: the current journeys/user_journeys_manifest.json is the separate publication-reader-gap manifest, not the pinned three-journey candidate- handoff manifest expected by the model and fixtures. This packet's reader manifest now preserves that pinned three-journey shape, including its evidence schema, review-verdict requirement, exact allowlist, and expected results, while recording the user-manifest mismatch as unresolved. That observation is a declaration-reconciliation defect in this route, not a product runtime defect. The separate reader-gate observation — journey journey.resolve-reader-journey-harness-decision, command python3 tests/check_documentation_smoke.py, exit status 1, and output Operation not permitted after localhost socket access was denied — remains an environment-specific evaluation blocker and supplies no recurrence, affected claim, or repair target.

Workstream Selection

The selected workstream is Internal Knowledge, as declared by journeys/candidate-evidence-handoff-manifest.json. The audience is Lee, the agent-orch contract owner, and the intended outcome is a bounded, operator-facing evidence handoff that records acceptance coverage, artifact authority, source references, validation commands, output locations, and unresolved blockers without crossing a platform-owned transition boundary.

Employee Onboarding and Customer Education were not selected for this bounded cycle because the sealed candidate-evidence manifest names Internal Knowledge as the workstream and supplies no competing audience, intended outcome, or authority declaration for either alternative. This is a scope boundary, not a product judgment about those workstreams; selecting one would expand the packet beyond the declared evidence question and require new authority rather than resolving the present contract conflict.

Conflicting Declarations

The observed human-readable declaration is docs/candidate-evidence-preflight-contract.md, with its stated companion journeys/user_journeys_manifest.json: the contract names AC-1 through AC-5, five canonical natural-language journeys — As a maintainer, verify complete candidate-evidence contract coverage., As an independent reader, match each journey name to its contract declaration., As a maintainer, check every preflight command against the allowlist., As a reviewer, validate the evidence record schema before accepting a result., and As an operator, require the independent review verdict before handoff completion. — and the JSON-tool commands python3 -m json.tool journeys/user_journeys_manifest.json and python3 tools/validate_content.py. The separate executable/model/fixture route in journeys/candidate-evidence-handoff-manifest.json and the repaired reader manifest journeys/candidate-evidence-contract-decision-packet.json, models/candidate_evidence_handoff_contract.json, and the candidate-evidence fixtures pins exactly three journeys — journey.candidate-evidence-handoff-preflight, journey.candidate-evidence-handoff-template, and journey.candidate-evidence-handoff-documentation-validation — with AC-1 through AC-3 and the allowlist python3 -B tests/check_documentation_smoke.py plus python3 -B -m pytest -p no:cacheprovider tests/test_product_contract.py. The current user-journey file instead identifies journey-manifest.publication-reader-journey-gaps and carries the three journeys journey.find-authoritative-publication-gap-explanation, journey.follow-documentation-gap-closure-procedure, and journey.verify-candidate-only-packet-boundary, with four JSON-tool commands. The packet manifest is synchronized to the executable/model/fixture route for its reader-facing evidence shape; the existing test oracle still treats the separate user-manifest path as its input, so this remains an observed route inconsistency to reconcile at the owning boundary, not proof that either declaration wins. The handoff manifest adds the selected workstream, goals, audience, entry points, and journey-level traces; the model and packet manifest add the read-only evidence schema, preflight tool, review-verdict requirement, and expected journey exit codes; neither addition canonizes the five-check document. The valid fixture mirrors the three journey names, traces, exact commands, and expected exit codes [0, 0, 1]. The disallowed-command fixture intentionally presents python3 tools/validate_content.py as a command claim for rejection because it is not an exact member of the executable/model allowlist. These manifest, model, fixture, and allowlist contents are preserved declarations, not proof that a command ran or that the route was approved. The current declarations remain separate and unresolved; no input or owner is claimed to have changed or approved them.

Decision Matrix

The matrix is a decision aid, not a change record. Its owner entries distinguish what the sealed inputs establish from ownership that still requires confirmation. The one recommended default is reversible: leave every competing input unchanged pending an approved later update, while keeping this packet's reader-facing manifest synchronized to the already pinned executable/model/ fixture shape. This preserves the competing declarations and keeps a successful check on one route from being silently reused as evidence for the other. The current preflight-suite mismatch is therefore a reason to route a source-boundary reconciliation, not permission to edit the user-journey manifest, model, fixtures, validator, or competing allowlists in this packet.

Recommended Reversible Default

Keep the five-check/JSON-tool declaration and the three-journey/ -B pytest-or-smoke declaration unchanged, label the relationship as an unresolved contract conflict with a recorded deterministic mismatch, and park this packet for Lee's decision. The packet reader manifest is synchronized to the pinned three-journey evidence shape so its schema and command claims are reader-verifiable, but that output does not edit the human-readable contract, user-journey manifest, candidate-handoff manifest, model, validator constants, fixtures, or competing allowlists. A later approved contract update may define a canonical route and a migration owner; until then, no declaration wins, no expected exit code becomes execution evidence, and no missing owner is filled in by inference.

Approval Questions

Lee should answer only the bounded contract questions: Which declaration set is intended to be canonical for this candidate-evidence route? Who owns the reconciliation and the migration plan? Should the five human-readable checks, the three executable/model/fixture journeys, or an explicitly revised set be carried forward? What evidence and approval are required before synchronizing the competing contract, manifests, model, fixtures, and allowlist? Until those answers are supplied through the governed route, this packet records a conflict rather than an approval. Lee must also decide whether the observed suite mismatch should be routed to the owning manifest/model boundary, while keeping the separate localhost-denied reader observation as an environment-specific blocker. No manifest, model, fixture, allowlist, or owner is currently claimed to be changed or approved, and none of these questions authorizes execution, publication, promotion, scheduling, rollback, or another transition.

Candidate-Only Boundary

This is candidate-only Internal Knowledge material for Lee's decision. It does not approve, promote, publish, schedule, activate, roll back, create or change a release pointer, or write a live directory. It also does not establish a product runtime defect, affected claim, independent review verdict, or platform-owned attestation. The declaration-reconciliation mismatch is the bounded route issue recorded here; its owning repair target remains unset until Lee's governed decision. The only safe next state is the reversible parked candidate with all conflicting declarations preserved. A later contract owner may reconcile them through an approved update; that future action is outside this packet and must not be inferred from its page, registry entry, or journey manifest.

Acceptance Checks

• AC-1: The reader compares the human-readable five-check and JSON-tool declaration, the current publication-reader-gap user manifest, and the executable/model/fixture route's three pinned journeys and exact -B pytest or smoke commands, preserving the deterministic mismatch and each declaration as unresolved. The packet reader manifest exposes the same evidence schema and execution declarations without canonizing either route.
• AC-2: The reader selects the recommended reversible default: preserve the human-readable contract and competing input manifests, model, fixtures, and allowlists unchanged; keep this packet's reader manifest synchronized to the pinned handoff shape; route declaration reconciliation to its owner; and defer canonicalization to an approved later contract update.
• AC-3: The reader preserves the candidate-only approval boundary, treats the localhost-denied reader result as environment-specific, and does not infer approval, promotion, publication, scheduling, activation, rollback, release-pointer change, live-directory work, product runtime defect, affected claim, or platform-owned attestation from this packet.