# Deprecation/replacement proposal and closed synthetic export v1

These artifacts are synthetic, static evidence contracts. They are not canonical changes, deletion instructions, verified claims, rankings, search inputs, or publication authority. Both proposals remain held, ineligible, and require a later independent approval and explicit application path that this contract does not provide.

Each proposal has its own source-only claim, review, one-item queue, disposition audit, and dated review checkpoint. The existing provider-claim and reviewer-work-queue runtime validators run against each exact byte set. The claim's `syn_weh_…` context ID is exactly `syn_` plus the proposal's canonical target ID. Actors, evidence, and workflow IDs differ between proposals. Provider-claim fields cannot express a lifecycle transition authoritatively: the service-description change is untrusted lifecycle evidence only, never deprecation authority, and the `needs_more_evidence` disposition must never infer candidate eligibility. Proposal evidence hashes the exact UTF-8 claimant-locator string while raw locator fixtures remain source-only and are not published.

Lifecycle comes from canonical `verification_status`: only `deprecated` means deprecated, and `replaced_by` is allowed only on deprecated records. A proposal may target any current non-deprecated status, including `legacy_unverified`, and preserves that exact status in its transition. A replacement must exist, differ from the target, be non-deprecated, not be disputed, and have no `replaced_by`. Runtime validation compares canonical and indexed-record `id`, `verification_status`, and `replaced_by`. The records API includes `replaced_by` only when populated, so absence is bound as null/absent rather than inventing a field.

The exact-byte checkpoint binds reviewer identity, review ID, decision, conflict state, reviewed-on date, and disposition head. `reviewed_on` is derived from that checkpoint and the effective date must follow it. This is synthetic fixture provenance, not caller-authored time presented as trusted wall-clock time.

The closed v1 export is deliberately not a general signed append-only log. Runtime and schema require exactly two proposals and two events; runtime also binds the known proposal, target, evidence, and event IDs, exact proposal byte pins, expected counts, chain, and final head. This rejects truncation even when a prefix is fully recomputed. SHA-256 detects byte mismatch after trusted acquisition; it is not publisher authentication.

Recursive leakage validation is part of `validateProposal` and `validateAuditExport`. After NFKC normalization it rejects URI schemes, protocol-relative locators, scheme-less hostname/domain shapes (including `.invalid`), email and `@` contact forms, ASCII or Unicode decimal phone-like runs, and text outside a bounded ASCII closed grammar. Synthetic `.invalid` identities are exempt only at the proposal's exact structural identity paths; exact structural IDs, hashes, dates, paths, and contract tokens are also exempt. Deliberately obfuscated human text outside this deterministic detector is not claimed to be detected; exported free-text is constrained to the ASCII closed grammar.

The source contracts and their public copies are intentionally tracked and committed together with exact bytes. The production build command is a strictly read-only exact-parity gate: it inspects both trees and fails closed if either is absent, unsafe, has an unexpected manifest, or differs. It never creates, stages, writes, renames, removes, or cleans either tree. It is not a publisher, generator, or live service. This design deliberately prefers committed parity over unsafe portable directory mutation.

The exported absent-output regeneration helper used by contract tests has a narrower cooperative-single-writer contract enforced by an exclusive lock. Under that model, it publishes a complete staged directory or no directory and retains immediate post-hook validation, pinned descriptors, and root identity checks. Node exposes no portable descriptor-relative/no-replace directory rename, so the helper does not claim protection from a same-UID filesystem actor that ignores the lock and changes a pathname between the final check and `renameSync`.

All identities and evidence are synthetic `.invalid` examples. No intake, admin, authentication, accounts, persistence, telemetry, outreach, billing, SLA, DPA, security, commercial, or live write service exists. `/deprecation-proposals/v1/**` remains GET/HEAD/OPTIONS-only static publication.