id: page.candidate-evidence-provenance title: Candidate Evidence Provenance visibility: public candidate_visibility: candidate-only candidate_only: true audiences: - Lee - current company operators - future Internal Knowledge playbook authors - independent readers reading_modes: - executive - engineer - ai claim_refs: [] source_refs: - source.naming-decision - source.documentation-boundary - source.platform-delivery-contract

Candidate Evidence Provenance

Purpose

This is a bounded provenance packet for Lee and auto-orch operators working in the selected Internal Knowledge workstream. It explains what the candidate evidence actually establishes, where each statement comes from, which product tests are relevant, and which facts remain owned by a platform evaluator or require Lee. The packet contains evidence statements rather than a new semantic product claim, and its YAML header is synchronized with the page registry and the compatibility metadata consumed by the product validator.

The packet keeps four boundaries visible: sealed authority is not employee modifiable, a preserved validator result is not a new local run, an environment-denied reader attempt is not proof of a recurring product defect, and candidate-only product evidence is not approval or publication. Missing recurrence, product impact, or transition authority is recorded as a gap; it is never filled with guessed prose or an invented repair target.

Evidence Matrix

The rows below are candidate-evidence claims made by this packet, not entries in the governed semantic claims registry. Each row names the direct evidence owner and fields, then names the sealed-authority boundary and the exact page identity fields that make the statement traceable. The identity anchor is the same in every row: content/candidate-evidence-provenance.md has page ID page.candidate-evidence-provenance, title Candidate Evidence Provenance, public/candidate-only visibility, empty claim_refs, and the three source references, and the matching object exists in registries/pages.json. A product test can validate a contract or structure; it cannot replace platform-owned attestations or create missing runtime evidence.

| Candidate-evidence claim | Direct evidence owner and fields | Sealed-authority and page-identity trace | Relevant product coverage, mismatch, and Lee decision | | --- | --- | --- | --- | --- | | CE-1 — Authority boundary: revision 2026-08-08, exactly the three logical source IDs, and employee_may_modify: false. | Direct owner: sources/authority.json, fields authority_revision, source_files, and employee_may_modify; corroboration: registries/sources.json, each matching id and disclosure. | Sealed boundary anchor: sources/authority.json is employee-immutable; page identity anchor: the page header and registries/pages.json entry both carry the page ID, title, visibility, candidate-only fields, empty claim_refs, and the same three source_refs. | The product contract covers schema/reference and source-boundary structure, but neither test substitutes for the sealed authority. No mismatch is recorded; all three source records are public-safe. No product decision is requested. | | CE-2 — Preserved validator: six independent Agent-Orch validator records supplied for this handoff retain their exact commands, statuses, counts where supplied, summaries, durations, outputs, and hashes. | Direct owner: the preserved validator artifact supplied for this step, represented in releases/candidate-evidence-provenance-candidate.json under preserved_validator_evidence.records; fields are keyed by source_step_id, command, exit status, counts, duration, summary, output, and evidence hash. | The sealed authority constrains the product source boundary but does not attest validator execution. The page header and registry identity remain the same synchronized identity anchor for this evidence packet. | Records 1–3 and 5 are the exact pytest command with exit 0, 10 passed, and hashes 087109894e15960d623ee618239670a42955cf367c99d22a0c2f2c78223489e5, 01cc6a08169e3a97d213417792d229c42152585980064a1d5bd6db9ba84a1e7e, 593ce049b9a988035ad4c23589ff3cd4e08f85567eda7c2d00adf542cbece936, and 50f61ea74d7894e238a52f31c0b1f05a8b97a3b67cdafb033a230d4994372a57; records 4 and 6 are tools/build_projection.py, exit 0, hashes fe30b42ea3bd9d571bb0d29359163c3709c291c270cf426173a267060b438ee6 and dac432306c6aa04bdd06d2d3b9eb9520903f180531ef31070df8d43e2322acb0. They are preserved evidence, not a local rerun, and Lee is not asked to treat them as approval or platform attestation. | | CE-3 — Reader-gate observation: one attempt of journey.resolve-reader-journey-harness-decision exited 1 with Operation not permitted because localhost socket access was denied. | Direct owner: the platform-owned evaluator record described by questions-for-the-human.md#blocking-question and the read-only journeys/reader_journeys_manifest.json; fields are journey ID, exact command, attempt count, exit status, output, and environment context. | The sealed authority remains the source-boundary anchor, while the page header and registry entry identify the exact candidate page to which this observation is attached. Neither identity anchor turns the observation into a product claim. | Evidence gap, not a confirmed product mismatch: the single environment-specific failure establishes no recurrence, retry count, affected claim, or repair target. The product journey-fixture test covers structure only. Lee must retain the gap and route the exact command for permitted follow-up. | | CE-4 — Candidate-only boundary: the record is unpublished and unpromoted, with no pointer, scheduling, rollback, activation, or live-directory write. | Direct owner: releases/candidate-evidence-provenance-candidate.json fields status, candidate_only, published, promoted, and publication_boundary, with AGENTS.md as the local boundary contract. | The sealed authority is unchanged; the synchronized page identity is the header/registry pair named above. The candidate record's content_identity repeats that pair and names the journey manifest, so the boundary facts cannot be detached from the page. | No mismatch is claimed. The absence of a prior approved version and rollback target is explicitly not_established, not a failed lookup to repair. No transition decision is requested; approval, promotion, publication, scheduling, rollback, and activation remain separately governed. | | CE-5 — Workstream context: this bounded packet belongs to the selected Internal Knowledge workstream and serves Lee, current operators, playbook authors, and independent readers. | Direct owner: questions-for-the-human.md#affected-work and registries/workstream-selection-receipt.json; synchronized context is repeated in the page header, registry entry, candidate content_identity, and journey manifest. | The sealed authority is the immutable source-boundary context, not a workstream selector. The synchronized page identity proves which packet carries the context; claim_refs: [] keeps it from becoming a new governed semantic claim. | No contradiction is supplied; this is context, not a fresh scheduling result. The product suite does not reselect the workstream. No decision is requested from Lee about scheduling or transition. |

Mismatch Status

The product-side source and identity facts are aligned: the page, registry entry, candidate record, and journey manifest use the same page identity, title, visibility, audience, reading modes, claim references, and logical source references. All six preserved validator records are retained with the exact fields supplied by the authoritative artifact; the four pytest records include their counts and summaries, while the two projection records have no test-count claim. These are evidence alignments, not a claim that this step executed any recorded validator or that a platform gate passed.

One evidence gap remains intentionally open. The platform-owned reader-gate record contains one denied attempt with exit status 1 and output Operation not permitted; it does not contain recurrence, a retry count, an affected claim, or a named repair target. Therefore the mismatch status is environment-specific evaluation blocker; product defect not established. That status must not be rewritten as a product harness failure, and the reader manifest is a traceability input rather than a repair target. The absence of a prior approved version or rollback target is separately recorded as an honest absence, not as an evidence mismatch.

Unresolved Decisions

The only decision genuinely requiring Lee in this packet is bounded and reversible: retain the candidate-only evidence blocker as unresolved and route a permitted follow-up evaluation in an environment with the required localhost reader service and socket access. A later authoritative reader record must provide the journey ID, exact allowlisted command, exit status, observed output, retry count or recurrence evidence, source references, and affected work item before anyone names a product defect or repair target. This is a decision about where evidence should be routed, not permission to change the manifest, authority, claims, governance controls, or platform gates.

Lee is not being asked to approve, promote, publish, schedule, activate, roll back, create a release pointer, or write a live directory. No decision is inferred from the preserved validator result, the workstream label, the page's public visibility, or the existence of this candidate file. Until authoritative follow-up evidence and any separately governed decision arrive, the smallest safe disposition is to leave the candidate parked and unchanged.

Acceptance Checks

• AC-1 — Source and identity trace: The reader verifies the authority revision 2026-08-08, the exact three authority-listed logical source IDs, their public-safe registry records, employee_may_modify: false, and the synchronized page header and registry identity without copying private governance material or asserting a new semantic claim.
• AC-2 — Preserved validator trace: The reader reports all six preserved records supplied for this handoff: the four pytest records from step_01_seal_authority, step_03_author_provenance_packet, and the two step_04_repair_and_verify_packet attempts, plus the two step_05_generate_projection records. The pytest records retain their exact command, declared bytecode-disabled command, exit 0, pass status, 10 passed with 0 failed and 0 skipped, durations 3.150056, 3.205681, 3.18602, and 3.298212 seconds, summaries 10 passed in 2.60s, 10 passed in 2.64s, 10 passed in 2.62s, and 10 passed in 2.74s, empty stderr, and hashes 087109894e15960d623ee618239670a42955cf367c99d22a0c2f2c78223489e5, 01cc6a08169e3a97d213417792d229c42152585980064a1d5bd6db9ba84a1e7e, 593ce049b9a988035ad4c23589ff3cd4e08f85567eda7c2d00adf542cbece936, and 50f61ea74d7894e238a52f31c0b1f05a8b97a3b67cdafb033a230d4994372a57; the projection records retain tools/build_projection.py, passed status with exit 0, empty output, and hashes fe30b42ea3bd9d571bb0d29359163c3709c291c270cf426173a267060b438ee6 and dac432306c6aa04bdd06d2d3b9eb9520903f180531ef31070df8d43e2322acb0. No record is rerun or replaced.
• AC-3 — Evidence-gap classification: The reader records the one journey ID, exact command, exit status 1, and Operation not permitted output with its denied-localhost context, and distinguishes that environment-specific evaluation blocker from an unestablished recurrence, affected claim, product defect, or repair target.
• AC-4 — Lee decision and candidate boundary: The reader identifies Internal Knowledge and the packet audience, states Lee's smallest decision to retain the unresolved blocker and route permitted follow-up evidence, confirms the honest absence of prior-version and rollback facts, and confirms that no approval, promotion, publication, scheduling, activation, rollback, pointer, or live-directory action occurred.

This packet is complete only as a candidate-evidence provenance record. A future evaluator or decision owner must supply any missing runtime evidence or transition authority; this page does not manufacture either one.