Open_Ultra_SAST/.kiro/specs/detection-core/tasks.md

Implementation Plan

Merge record

Previous v1 item	Disposition in this plan
Completed groups 1–7 and 8.1	Retained as regression substrate; their former requirement mappings do not count toward v2 coverage
Previous task 8.2	Permanently parked after admission NO-GO #3; no task below revives that arm
Previous tasks 8.3–8.4	Superseded by v2 consumer and proof conformance work; no rollout or live capability enablement is included

Task constraints

• New and amended code keeps McCabe complexity at most 10, functions at most 50 logical lines, and new modules at most 400 logical lines.

• Core owns contracts and pure validation only; analyzers, model execution, proof execution, persistence, acquisition, and rollout remain with adjacent owners.

• Every zero-result test first proves nonzero readable input; an unread input is an instrument failure.

• Historical v1 artifacts remain byte-identical. V2 creates a new baseline and is never trended against v1.

• The parked authorization arm remains parked. Admission orchestration uses synthetic/reference inputs only and does not consume a live population.

• Existing target facts may be schema-migrated without expanding vocabulary or behavior.

• 1. Establish migration-safe foundations

• 1.1 Freeze historical v1 artifacts and the reviewed migration inventory

  • Pin representative v1 trace and report bytes and hashes as immutable regression fixtures.
  • Provide an independent schema-routed read-only decoder that validates committed v1 artifacts without importing the compatibility namespace, constructing v2 determinate outcomes, or exposing a writer or converter.
  • Freeze the reviewed initial set of v1 readers and writers with stable entry identities, paths, symbols or capabilities, owner boundaries, and open migration status.
  • Preserve every inventory identity permanently and allow only monotone transitions from open to v2_migrated or retired; fail unreadable or zero-byte sources, additions, deletions, and rekeying.
  • Preserve v1 as migration input only and never treat it as v2 conformance or a comparable trend baseline.
  • Done when fixture tests detect any byte or hash change, the decoder validates both historical schemas read-only, every inventory entry resolves to a nonzero source and valid target, and schema, status, or addition mutations fail.
  • Requirements: 14.3, 15.3

• 1.2 Build the strict canonical codec and resolver-backed artifact boundary

  • Produce deterministic UTF-8 JSON with full SHA-256 identities, stable mapping order, and retained sequence order.
  • Refuse non-finite numbers, unsupported values, unknown schemas, duplicate logical identities, and malformed digests.
  • Validate resolved bytes, length, storage receipt, retention identity, trusted store, and configured size limits.
  • Provide deterministic in-memory resolver and receipt fixtures for later contract tests.
  • Done when identical values produce byte-identical output and each content or receipt mismatch fails before parsing.
  • Requirements: 1.4, 10.4

• 2. Implement canonical semantic, provenance, and evidence contracts

• 2.1 (P) Represent family-neutral semantic relations and observations

  • Cover registration, invocation, call, return, value transformation, operation effect, and constraint effect.
  • Preserve role, location, conditions, provenance, and independent complete, incomplete, or unresolved status.
  • Refuse conflicting complete candidates by producing explicit ambiguity rather than selecting one.
  • Done when contract tests exercise every relation kind and all three relation statuses with canonical identities.
  • Requirements: 1.2, 4.1, 4.2, 4.3, 5.2
  • Boundary: Semantic Evidence
  • Depends: 1.2

• 2.2 (P) Validate complete input and decision provenance

  • Stamp analyzer, family contract, fact set, acquisition, configuration, population, and change-input identities.
  • Require the closed named-input role set and resolve every referenced input through the trusted artifact boundary.
  • Keep model and proof identities outside the immutable deterministic packet.
  • Done when every stamp field has a tamper test and unreadable or substituted named input is refused.
  • Requirements: 10.1, 10.4
  • Boundary: Provenance and Lineage
  • Depends: 1.2

• 2.3 Enforce append-only population custody

  • Construct and validate contiguous reviewed-custodian receipt chains against the complete current log.
  • Require compare-and-swap requests to name the expected log head and derive the next sequence and predecessor.
  • Make spent status monotonic and reject old prefixes, omitted receipts, broken chains, and later availability claims.
  • Provide deterministic in-memory custody-port and custodian fixtures for lineage and admission tests.
  • Done when concurrent requests have one valid successor and no fixture can restore a spent population.
  • Requirements: 12.2, 13.1, 13.4

• 2.4 Bind lineage purposes to exact influenced artifacts

  • Require each lineage use to name its purpose, influenced artifact, source population, label access, and current-chain receipt.
  • Enforce required and optional use counts for prompts, examples, thresholds, fitted models, facts, matching behavior, mappings, and promotion.
  • Distinguish fact ancestry that forbids all label access from development lineage that may use a different spent population.
  • Refuse protected-population influence, redirected artifact identities, wrong purposes, and incomplete receipt history.
  • Done when matching subjects cannot mask a wrong influenced artifact and contaminated populations are deterministically refused.
  • Requirements: 13.1, 13.3, 13.4

• 2.5 Bind immutable evidence packets to neutral decisions

  • Preserve family identity, security object, analyzed scope, ordered semantics, observations, family fields, completeness, and provenance.
  • Keep family decision codes separate from violation, satisfied, and indeterminate outcomes.
  • Require bounded scope for satisfaction, named reasons for indeterminate outcomes, and a valid deterministic, model-corroborated, or execution-backed basis.
  • Prevent incomplete or ambiguous required relations from producing violation or satisfaction.
  • Done when positive, satisfied, and incomplete records round-trip canonically and every invalid packet/decision combination is refused.
  • Requirements: 1.1, 1.2, 1.3, 2.1, 2.2, 2.3, 2.4, 2.5, 10.1

• 3. Add vulnerability-family contracts and unlike reference families

• 3.1 Validate a closed vulnerability-family declaration

  • Require family/schema versions, ecosystems, security-object fields, roles, decisions, outcome rules, completeness conditions, residual questions, and indeterminate reasons.
  • Enforce typed family fields and exact ecosystem/schema scope.
  • Declare whether each role accepts product evidence or requires reviewed excluded-dependency facts.
  • Refuse undeclared fields, roles, decisions, reasons, or determinate outcomes without their minimum evidence.
  • Done when the family registration matrix accepts only declared combinations and reports unsupported scope without cross-family fallback.
  • Requirements: 1.3, 2.1, 2.4, 3.1, 3.2, 3.3, 3.4, 4.4, 9.1

• 3.2 Build exact family catalog resolution and capability declarations

  • Re-derive every contract and catalog digest and require canonical ordering and unique family/version/schema identities.
  • Resolve a contract only when family, digest, and ecosystem identify exactly one entry.
  • Validate that each family capability names its contract, readiness fixtures, development population, and admission boundary.
  • Done when duplicate/substituted catalog entries and each missing or corrupted capability field are refused.
  • Requirements: 3.1, 3.3, 3.4, 14.5

• 3.3 Create obligation and taint-flow reference conformance fixtures

  • Model an operation-plus-constraint family and an ordered source-to-sink family without target vocabulary.
  • Provide positive, negative, and ambiguity or missing-evidence cases for both semantic shapes.
  • Require each family to produce violation, bounded satisfaction, and indeterminate output through the same validators.
  • Done when both fixture suites pass without adding a family-specific field to any shared core contract.
  • Requirements: 3.5, 8.2

• 4. Expose operational coverage, budget, and readiness gates

• 4.1 (P) Account for instrument reads and every semantic-stage outcome

  • Count reads, questions, sites considered and recognized, transitions, security objects, constraints, determinate outcomes, and findings.
  • Put every considered relation in exactly one complete, incomplete, or unresolved bucket.
  • Fail unopened or zero-byte tracked input and diagnose the last verified nonzero stage and first missing expected output.
  • Done when stage-by-stage fixtures distinguish a valid zero from unread input and identify every injected first failure.
  • Requirements: 5.1, 5.2, 5.3, 5.4, 5.5, 15.2, 15.4
  • Boundary: Coverage Funnel
  • Depends: 2.1, 2.5

• 4.2 (P) Derive and enforce measured workload budgets and change scope

  • Record changed regions, semantic-transition count, changed bytes, and total reply time.
  • Derive workload-class budgets with sample count, percentile, reference workload, reference hardware, and canonical identity.
  • Resolve the changed-byte measurement and refuse missing, zero, non-finite, or incompatible complexity data.
  • Reject evidence and claim anchors outside the supplied affected scope and name the exceeded derivation on budget failure.
  • Done when class derivation is deterministic and scope escape or elapsed-budget excess yields a named gate failure.
  • Requirements: 6.1, 6.2, 6.3, 6.4
  • Boundary: Budget and Scope
  • Depends: 1.2, 2.5

• 4.3 Record ordered readiness evidence with explicit evidence-use roles

  • Cover instrument, recognition, transitions, constraints, pairs, development, admission, and consumer integration in fixed order.
  • Bind each result to arm/family/ecosystem, analysis identity, population use, fixtures, predecessors, measurement, and correction lever.
  • Keep regression, development, repository-holdout, fresh-admission, and integration evidence uses non-interchangeable.
  • Done when each stage accepts the correct positive/negative/ambiguity triplet and rejects the wrong evidence-use role.
  • Requirements: 8.1, 8.2, 8.6

• 4.4 Stop promotion on failed, absent, or stale prerequisites

  • Authorize a stage only when every ordered predecessor is current and passed.
  • Derive transitive staleness from core schema, semantic vocabulary, family, facts, acquisition, configuration, model, and outcome mapping.
  • Return the first failing layer and named correction lever without mutating historical results.
  • Done when one changed identity makes all dependent later results stale and later population/integration gates refuse to run.
  • Requirements: 8.3, 8.4, 8.5, 15.5

• 5. Replace semantic extension points with reviewed fact packs

• 5.1 Validate versioned packs and independent review evidence

  • Bind schema, family, ecosystem, language, stable facts, declared roles, normalized content, and review evidence.
  • Accept source, official-documentation, or independently reviewed behavioral evidence under a trusted review policy.
  • Resolve conflict disclosures and require producer/reviewer independence where behavioral evidence is used.
  • Reject label-derived semantic-fact ancestry, unknown scope/roles, missing review, and inconsistent digests.
  • Done when the schema/scope/review matrix accepts only fully reviewed label-isolated packs.
  • Requirements: 11.1, 11.4, 13.3

• 5.2 Validate complete structural observations and matcher lineage

  • Match the declared requirement set, including qualified name, shape, receiver, target, argument, and configuration evidence as applicable.
  • Resolve every observation artifact and require its identifier set to equal the fact’s complete structural requirements.
  • Bind matcher revision, behavior digest, and current lineage to the exact evaluated product location.
  • Prevent name-only, partial, fabricated, ambiguous, or protected-population-contaminated matches from becoming complete.
  • Done when only a fully observed structural match with valid matcher lineage is eligible for effect application.
  • Requirements: 10.2, 11.2, 11.3, 13.4

• 5.3 Apply declared fact effects with reproducible provenance

  • Materialize only relation kinds, roles, source/target roles, conditions, and effects declared by the matched fact and family.
  • Attach exact pack, fact, product location, structural observation, matcher, and match-reference identities to every derived relation.
  • Preserve unmet conditions as incomplete evidence and conflicting eligible matches as unresolved ambiguity.
  • Mark label-influenced matching behavior or promotion as spent before the relation can participate in evaluation.
  • Done when valid matches yield canonical effects while partial and ambiguous cases remain non-determinate with named reasons.
  • Requirements: 4.1, 4.2, 4.3, 10.2, 11.2, 11.3, 11.5, 13.4

• 5.4 Revalidate fact-derived relations and enforce the dependency boundary

  • Re-open referenced packs, facts, match evidence, review policy, lineage, custody, and resolved bytes for every fact-derived relation.
  • Reject undeclared roles, invalid scope, inconsistent content, and fact provenance that cannot be reproduced.
  • Require reviewed semantic facts for determinate behavior attributed to excluded dependencies.
  • Preserve missing dependency knowledge as named incomplete evidence rather than product-derived safety.
  • Done when product-only dependency behavior is refused, a missing fact stays indeterminate, and the reviewed structurally matched equivalent is accepted.
  • Requirements: 2.4, 4.4, 10.4, 11.4, 11.5

• 6. Add bounded model handoff and semantic shortcut probes

• 6.1 (P) Preserve reproducible model requests, results, and responses

  • Present the canonical evidence, completeness snapshot, family declaration, and declared residual question without importing a model runtime.
  • Freeze provider, model, program, prompt, examples, fitted component, configuration, adapter, decision mapping, and input-bundle identities before execution.
  • Preserve normalized responses plus one bounded redacted inline value or trusted immutable artifact, including failures.
  • Done when matching success/failure fixtures round-trip and substituted request, packet, response, program, or mapping identities are refused.
  • Requirements: 9.1, 9.2, 10.3
  • Boundary: Model Handoff
  • Depends: 2.4, 3.1

• 6.2 Apply model results without rewriting deterministic evidence

  • Validate current prompt/example/fitted-model/mapping lineage against the evaluated population and declared artifacts.
  • Reject proposer/adjudicator role collision and results for another packet, family, residual, or mapping.
  • Allow model-corroborated output only when deterministic residual prerequisites are complete.
  • Prevent model output from creating semantic relations, satisfaction over missing evidence, or execution-backed basis.
  • Done when accepted derivation leaves the evidence packet byte-identical and every incomplete or contaminated path remains indeterminate.
  • Requirements: 2.4, 2.5, 9.3, 9.4, 9.5, 13.1

• 6.3 (P) Evaluate independently reviewed equal-semantics reversed-surface probes

  • Derive semantic projections from records and family contracts rather than trusting caller summaries.
  • Resolve distinct surface artifacts and independently reviewed semantic-equivalence evidence.
  • Reject unequal semantics, digest-only review, non-finite tolerances, and fabricated passed summaries.
  • Detect a surface-shape component while accepting a relation-based component within its pre-registered tolerance.
  • Done when probe results are reproducible solely from canonical probe inputs and review policy.
  • Requirements: 13.2
  • Boundary: Probes
  • Depends: 3.3, 5.1

• 7. Compose validated evidence into bounded decisions and consumer output

• 7.1 Revalidate deterministic and fact-derived records through one shared context

  • Bind the exact catalog, packs, model declarations, lineage set, review policies, provenance trust, and custody policy.
  • Resolve the family contract and all seven named provenance inputs for each raw record.
  • Re-run family and fact validation and reject embedded pack, lineage, or named-input substitutes.
  • Done when raw, forged, and context-mismatched records cannot reach admission or consumer decision code.
  • Requirements: 4.4, 10.1, 10.2, 10.4, 12.6, 14.1

• 7.2 Replay model derivation at the shared validation seam

  • Require deterministic records to omit model derivation and model-corroborated records to include both request and result.
  • Re-run model application from the pre-model record and compare the derived record canonically.
  • Refuse constructible “validated” markers or model programs outside the context.
  • Done when admission and consumer tests exercise the same validator and neither can bypass it with a raw record.
  • Requirements: 9.2, 9.3, 9.4, 9.5, 10.3, 10.4, 12.6, 14.1

• 7.3 (P) Derive defect claims, bounded satisfaction, and bounded silence

  • Require exact change-tied locations and complete evidence for defect claims.
  • Carry completed question identities and exact scope for satisfaction.
  • Preserve named coverage reasons and record identities for every undecided question.
  • Keep incomplete paths silent unless a separate complete path independently supports a claim.
  • Done when mixed complete/incomplete fixtures produce supported claims plus bounded silence without any unbounded clean result.
  • Requirements: 2.2, 2.3, 7.1, 7.2, 7.3, 7.4, 14.4
  • Boundary: Verdict and Proof
  • Depends: 2.5, 3.1

• 7.4 Validate differential proof attachment without enabling rollout

  • Re-derive reviewed producer, sandbox, oracle, affected/safe side, control, witness, and verification identities.
  • Resolve all proof artifacts under the supplied producer, reviewer, store, and byte-limit trust policy.
  • Upgrade basis only for demonstrated affected-only behavior tied to the same family, packet, location, and change/control.
  • Reject opaque, self-asserted, inconclusive, same-side, or mismatched proof records.
  • Done when only the valid differential fixture yields execution-backed basis and no attachment changes rollout policy.
  • Requirements: 2.5, 9.6, 14.2

• 7.5 Integrate validated records, proof, scope, and budget at the core consumer edge

  • Accept raw validation envelopes and call the shared validator before creating any output.
  • Preserve every bounded-silence reason and reject records or anchors outside the supplied change scope.
  • Apply optional proof attachments through the proof validator and include all processing in total elapsed time.
  • Return defects, satisfactions, silence, input identities, complexity, and measured budget identity.
  • Done when a synthetic push returns a bounded verdict and scope, trust, or deadline violations fail explicitly.
  • Requirements: 6.4, 14.1, 14.4
  • Depends: 4.2, 7.2, 7.4

• 8. Implement fixed measurement and leakage-safe admission

• 8.1 (P) Define comparable baseline identities and fixed metric algebra

  • Bind arm, population/freeze, claimed scopes, exact contract/fact/model sets, acquisition, analyzer, configuration, denominator, threshold set, and outcome mapping.
  • Define closed numerator/denominator rules for pair correctness, recall, fixed and ordinary false alarms, precision, semantic coverage, and model success.
  • Require Wilson 95 intervals with numerator and denominator; serialize zero denominators as null and prevent them from passing.
  • Treat any identity mutation as a new baseline and refuse cross-arm or cross-scope aggregation.
  • Done when a baseline mutation matrix and two-arm isolation fixture distinguish every non-comparable result.
  • Requirements: 11.6, 15.1, 15.3
  • Boundary: Measurement
  • Depends: 4.1, 4.4

• 8.2 Build complete measurement records and typed repository-holdout reports

  • Record family decision vocabulary, neutral outcomes, evidence bases, fixed metrics, semantic funnel, model outcomes/failures, instrument failures, runtime, and readiness ancestry.
  • Require every later-stage record to carry current prerequisite readiness stage results and digests.
  • Define a typed repository-holdout report with an explicit evidence-use role, training and holdout manifest references, repository identities, fitting lineage, and distinct measurement/report identities.
  • Refuse zero or clean-looking results unless tracked input reads and prerequisite semantic stages passed.
  • Done when missing metrics, counts, failure fields, readiness ancestry, or holdout-report identity fields invalidate the corresponding record.
  • Requirements: 13.2, 15.1, 15.2, 15.4, 15.5

• 8.3 Validate independently reviewed census and manifest payloads

  • Canonically bind every substantive census and manifest field into separate review-subject digests.
  • Require producer/reviewer separation, admitted reviewer identity, allowed identity pairing, and resolver-validated conflict disclosure.
  • Reject self-review, copied attestations, unknown reviewers, malformed review digests, and unreadable disclosures.
  • Preserve aggregate census cardinalities without exposing case identities or per-case labels.
  • Done when only independently attested label-blind payloads can proceed to manifest validation.
  • Requirements: 12.1, 12.2

• 8.4 Validate exact admission context, readiness, scope, sets, and threshold lineage

  • Bind the exact evidence-validation context, reviewed census, denominator, thresholds, readiness results, untouched population, and current custody head.
  • Re-derive claimed scopes and exact contract, fact, model, threshold, and outcome-mapping sets from canonical objects.
  • Require current instrument-through-development readiness with matching analysis identity and evidence-use roles.
  • Validate prompt, example, fitted-model, fact, matcher, mapping, promotion, and threshold lineage before labels open.
  • Reject label exposure, acquisition drift, context substitution, stale readiness, scope mismatch, or prior spend.
  • Done when each refusal branch fails before feasibility and no digest-only set or lineage claim is accepted.
  • Requirements: 12.1, 12.2, 13.1

• 8.5 Refuse arithmetically impossible threshold configurations

  • Enumerate reachable counts from label-blind pair, case, semantic-site, and model-call capacities.
  • Evaluate count, rate, per-100, and Wilson-bound thresholds with the fixed comparator direction for each metric.
  • Require every grouped threshold to have at least one jointly attainable count assignment.
  • Done when the historical impossible-denominator case is a configuration refusal rather than a measured no-go.
  • Requirements: 12.3, 12.4

• 8.6 Validate the pre-label population-spend protocol inside core

  • Construct a label-release request bound to the exact validated authorization and current custody-log head.
  • Validate the returned receipt as the exact current-chain direct successor that changes the named population from available to spent.
  • Reject missing, stale, mismatched, non-successor, or availability-restoring receipts before scoring authorization.
  • Keep durable append, compare-and-swap execution, label release, persistence, crash handling, and concurrency outside core.
  • Done when only the exact spent successor authorizes scoring and every other receipt shape is refused without an external side effect.
  • Requirements: 12.2, 13.4

• 8.7 Validate the authenticated post-spend case release

  • Define canonical released-case bindings over case identity, scope, role, scoped pair identity, exact result digest, evidence-input digests, change-input digests, and input-manifest digest.
  • Bind the release to the population, manifest, authorization, preparation, exact current-chain spend receipt, custodian identity, and an independent review attestation.
  • Validate the release only after the exact spend successor and require one canonical binding for every supplied case and no others.
  • Reject missing, extra, duplicate, cross-scope, role-swapped, pair-swapped, result-swapped, or rehashed operational-payload substitutions before metric production.
  • Keep case identities and labels out of the pre-label census and make the external custodian, not the runner, authoritative for their post-spend association.
  • Done when the reproduced vulnerable/fixed payload swap and every release-field mutation fail before any admission metric is returned.
  • Requirements: 12.2, 12.5, 12.6, 13.4, 15.1
  • Boundary: Admission Case Release

• 8.8 Derive scoped admission metrics from canonical case evidence

  • Re-run shared evidence validation, instrument, budget, verdict, and proof validation for every case.
  • Consume only cases that exactly match the authenticated post-spend release; use its roles and scoped pairs while reconciling aggregate counts to the reviewed census.
  • Score quality only over pre-registered family/ecosystem scopes while retaining whole-population coverage.
  • Compute paired behavior, ordinary false alarms, semantic coverage, model outcomes, and all standard metrics without trusting runner aggregates.
  • Done when forged decisions, substituted contracts, invalid fact review, contaminated lineage, or case-count drift fail before metric production.
  • Requirements: 12.5, 12.6, 15.1, 15.2
  • Depends: 8.7

• 8.9 Assemble evidence-backed gates and the final admission report

  • Emit instrument, budget, readiness, and quality gates with reasons and supporting identities.
  • Bind the report to the validation context, authorization, pre-label spend receipt, authenticated case release, census, and complete case-result set.
  • Require every mandatory metric and gate before allowing GO; make model success mandatory when a model is baseline-configured or validated claimed-scope calls occur. Refuse undeclared claimed-scope calls before report production; make configured zero-call, missing-threshold, and failed declared-call cases NO-GO while ignoring out-of-scope-only calls.
  • Return an immutable admission replay bundle carrying the exact manifest, denominator, readiness, preparation, spend receipt, case release, cases, and derived report; give the bundle a canonical transport digest without treating it as a validation token.
  • Revalidate the replay against independently supplied current context, custody, and content resolution by re-running the complete derivation and requiring exact report and replay equality.
  • Keep model-corroborated, deterministic, and execution-backed counts separate.
  • Done when any missing/failed mandatory gate forces NO-GO, coordinated report/readiness/threshold/case substitutions are refused, and a complete passing synthetic fixture yields a reproducible replayed GO report.
  • Requirements: 12.6, 15.1, 15.2, 15.4, 15.5
  • Depends: 8.8

• 8.10 Authorize fitted components only from replayed probes and disjoint evaluation

  • Accept only the typed admission replay bundle from task 8.9, validate it first against current authoritative context/custody/content, and refuse raw admission reports or coordinated replay substitutions.
  • Resolve the component’s unique model declaration, family contract, review policy, and custody policy from the admission-bound context.
  • Re-evaluate every canonical probe input and require the derived result set to match the component evidence.
  • Consume the typed repository-holdout report from task 8.2 and validate its evidence-use role, training/holdout references, report identity, and fitting lineage.
  • Prove the report’s training and repository-held-out repository sets are disjoint.
  • Require an admission GO that was untouched before its bound label-release spend.
  • Done when fabricated summaries, caller-selected policy substitutes, overlapping repositories, contaminated lineage, or mismatched admission are refused.
  • Requirements: 13.1, 13.2, 13.4
  • Depends: 8.2, 8.9

• 9. Integrate adjacent producers and benchmark-owned orchestration

• 9.1 (P) Translate the parked authorization trace conservatively into v2 evidence

  • Move conversion out of the family trace domain and keep authorization vocabulary outside shared core modules.
  • Map missing per-hop knowledge to incomplete relations and indeterminate outcomes without behavior lifting.
  • Preserve existing parked-arm regression behavior and avoid any admission rerun or reactivation.
  • Done when adapter conformance matches the frozen v1 behavior while the authorization domain no longer imports v2 core types directly.
  • Requirements: 3.5, 14.3
  • Boundary: Authorization Adapter
  • Depends: 3.3, 7.2

• 9.2 (P) Translate hunt-owned model execution through the bounded handoff

  • Convert structured executor inputs and outputs to the canonical request/result contracts.
  • Keep prompt creation, provider calls, caching, parsing, and redaction in the hunt subsystem.
  • Reject mismatched declared results through core validation without importing DSPy into core.
  • Done when a fake executor success/failure pair crosses the adapter and core’s import census contains no model-runtime dependency.
  • Requirements: 9.1, 9.2, 9.3, 9.4, 9.5, 14.3
  • Boundary: Model Adapter
  • Depends: 6.2, 7.2

• 9.3 (P) Translate demonstrated search results into trusted proof attachments

  • Map existing typed affected/safe verification records without moving sandbox or oracle execution into core.
  • Preserve producer, control, witness, storage, and verification identities required by proof validation.
  • Refuse inconclusive and mismatched fixtures at the adapter/core seam.
  • Done when a canonical demonstrated fixture attaches successfully and every negative proof shape remains at its prior evidence basis.
  • Requirements: 9.6, 14.2, 14.3
  • Boundary: Proof Adapter
  • Depends: 7.4

• 9.4 Accept downstream reviewed fact-adapter conformance evidence

  • Consume the immutable conformance fixture and manifest produced by the downstream family adapter without constructing its contract, packs, matches, authority, or target data in core.
  • Re-run only the family-neutral fact-pack, fact-match, relation-application, full-evidence, canonical-reference, and import-boundary checks named by that handoff.
  • Verify the manifest accounts for complete, name-only, partial, substituted, self-authored, protected-population-contaminated, and legacy-projection-only cases.
  • Done when the downstream handoff is accepted by generic validators and core remains free of target imports; adapter implementation and target-specific fixtures remain downstream-owned.
  • Requirements: 10.2, 10.4, 11.1, 11.2, 11.3, 11.4, 11.5, 13.4, 14.3
  • Boundary: Fact Pack Adapter Conformance
  • Depends: 5.4

• 9.5 (P) Produce readiness and development records through benchmark-owned adapters

  • Construct canonical readiness results while leaving sequencing and persistence with benchmark workflows.
  • Emit development observations with v2 identities, evidence-use roles, instrument receipts, and prerequisite ancestry.
  • Stop a runner before population work when readiness is failed, absent, or stale.
  • Done when development fixtures pass through v2 and an injected semantic identity change prevents the later run.
  • Requirements: 8.1, 8.3, 8.4, 8.5, 8.6, 14.3, 15.5
  • Boundary: Benchmark Readiness Adapter
  • Depends: 4.4, 8.2

• 9.6 Integrate benchmark-owned admission scoring and guarded custody

  • Delegate neutral scoring to core while retaining population persistence and run orchestration in the benchmark.
  • Make the custodian the sole append-only writer and combine durable compare-and-swap spend plus label release as one guarded operation.
  • After the winning spend, produce and independently attest the canonical case release over the exact immutable result, evidence, change, and input identities supplied to scoring.
  • Supply expanded manifest, lineage, resolver, and validation-context identities without exposing labels early.
  • Exercise durable append, label release, case-release production, crash-before-append, crash-after-append, and concurrent-winner behavior at this external boundary.
  • Done when synthetic admission completes end to end, injected crash/concurrency cases prove labels reach at most the successful compare-and-swap winner, and swapped operational payloads are refused by core.
  • Requirements: 12.1, 12.2, 12.3, 12.4, 12.5, 12.6, 13.4
  • Depends: 8.9, 9.5

• 10. Complete the single-writer v2 migration

• 10.1 Isolate every live v1 contract and writer behind the closed compatibility namespace

  • Move all authorization-shaped v1 values into one compatibility contract owner and all live v1 serialization into its sole writer facade.
  • Limit the compatibility namespace to the canonical primitive needed for byte stability and prevent every v2 module from importing it.
  • Preserve the frozen v1 wire representation while eliminating independent contract or serializer implementations elsewhere.
  • Done when old writes remain byte-identical, the compatibility namespace is the only live v1 contract and write owner, and ownership/import tests refuse any duplicate implementation.
  • Requirements: 14.3, 15.3
  • Depends: 1.1

• 10.2 Convert the temporary public and module compatibility surfaces into explicit shims

  • Keep the old named top-level API and designated compatibility modules as explicit imports from the isolated namespace during migration.
  • Remove legacy definitions and re-exports from mixed v2 modules so each compatibility name has exactly one owner.
  • Keep the canonical v2 paths private until the final atomic cutover.
  • Done when the old named API remains compatible before cutover, direct imports of moved legacy symbols from mixed modules fail, and no shim owns an independent implementation.
  • Requirements: 14.3, 15.3

• 10.3 Build the syntax-only migration-boundary instrument

  • Prove every scoped source file is readable and nonzero before interpreting a zero result.
  • Report explicit compatibility-namespace imports, designated shim imports, named top-level v1 symbols, writer-facade references, and module-valued or dynamic core access without evaluating alias or data flow.
  • Validate immutable inventory identities and their monotone open, v2_migrated, or retired status transitions.
  • During migration, distinguish the designated compatibility implementation from the production-consumer scope; reserve repository-wide zero for post-deletion validation.
  • Done when an adversarial syntax matrix reports the exact forbidden sites and try/finally, comprehension, assignment, and generic-call alias shapes cannot turn an explicit forbidden reference into a false zero.
  • Requirements: 14.3, 15.3

• 10.4 Migrate or retire remaining registered production source-tree consumers

  • Move each registered non-benchmark production reader and writer to the canonical v2 contract or retire it within its owning boundary.
  • Update the matching stable inventory entry to v2_migrated or retired in the same change without removing or rekeying it.
  • Keep authorization analysis, model execution, proof execution, and other adjacent behavior in their existing owner boundaries while changing only their contract seam.
  • Done when every source-tree entry owned by core or an adjacent adapter is terminal and the verified nonzero production-consumer scope outside the designated compatibility implementation has zero forbidden references.
  • Requirements: 14.1, 14.3, 15.3
  • Boundary: Core and Adjacent Adapter Migration
  • Depends: 10.3

• 10.5 Migrate benchmark readiness and admission consumers

  • Move every registered benchmark reader and writer to v2 while retaining readiness sequencing, persistence, population custody, and admission orchestration in the benchmark boundary.
  • Update each matching stable inventory entry to v2_migrated or retired without changing its identity.
  • Preserve guarded spend, authenticated case release, fixed measurement, and bounded model behavior through the migration.
  • Done when benchmark production scope has zero forbidden consumer references outside the designated compatibility implementation, every benchmark entry is terminal, and synthetic v2 readiness and admission complete end to end.
  • Requirements: 8.1, 12.6, 14.3, 15.3
  • Boundary: Benchmark Readiness and Admission Adapters
  • Depends: 9.5, 9.6, 10.3

• 10.6 Migrate or retire registered test and operational-tool consumers

  • Move authorization assumptions into legacy or adapter tests, keep family-neutral contract tests on v2, and retain frozen v1 bytes only for decoder regression.
  • Move or retire registered operational-tool consumers without adding a second compatibility or write path.
  • Mark the corresponding stable inventory entries v2_migrated or retired and require every original entry to reach a terminal status.
  • Done when the complete original inventory is terminal and the boundary instrument proves a nonzero repository scope with no forbidden consumer reference outside the designated compatibility implementation.
  • Requirements: 14.3, 15.3
  • Boundary: Migration Tests and Operational Tooling
  • Depends: 10.4, 10.5

• 10.7 Delete v1 write capability and publish the single v2 surface atomically

  • Require every inventory entry to be terminal and the migration-time production-consumer boundary to be zero before deletion begins.
  • Delete the compatibility namespace, v1 writer facade, and temporary shims while publishing the canonical v2 modules and top-level exports in the same integration change.
  • Prove old top-level and submodule imports and writes fail and that no v1 serializer or converter remains.
  • Retain the independent read-only decoder for frozen historical bytes and refuse comparison between v1 and v2 baseline identities.
  • After deletion, require repository-wide zero with no compatibility exclusion.
  • Done when isolated-tree and repository tests show old imports and writes fail, v2 imports and writes succeed, historical bytes still validate, and the final nonzero boundary scan remains zero.
  • Requirements: 14.3, 15.3
  • Boundary: Single-Writer Cutover Integration
  • Depends: 10.6

• 11. Validate readiness, failure visibility, and implementation boundaries

• 11.1 Run both reference families through the complete synthetic readiness path

  • Start from a verified nonzero input and run recognition, transitions, security object/constraints, pair, development, reviewed synthetic admission, guarded spend, and consumer verdict.
  • Produce violation, bounded satisfaction, and bounded silence for both unlike families.
  • Require current prerequisite readiness identities at every later stage.
  • Done when both authored repositories complete the path without target-specific core fields or a real admission population.
  • Requirements: 3.5, 8.1, 8.2, 8.4, 8.6, 12.1, 14.1, 15.5

• 11.2 Inject one failure at every semantic and governance stage

  • Exercise unread/zero input, missing recognition, incomplete transition, missing constraint, pair mismatch, failed development, contaminated admission, and refused integration.
  • Verify each run stops at the first failing stage with a named correction lever and no later metric or clean result.
  • Mutate a semantic identity and verify transitive staleness through all dependent readiness and measurement records.
  • Done when every injected failure is diagnosed at its source and no late admission-only surprise remains.
  • Requirements: 5.3, 5.4, 5.5, 8.3, 8.4, 8.5, 15.4, 15.5

• 11.3 Verify bounded validation cost and total consumer deadline accounting

  • Measure canonicalization and validation across increasing relation, observation, receipt, and case counts.
  • Exercise large transition sets for linear behavior and bounded memory without weakening semantic checks.
  • Include optional model and proof processing in the same measured consumer budget.
  • Publish sample count, percentile, workload, hardware, and derived budget through the fixed measurement contract.
  • Done when performance fixtures satisfy the derived workload envelope and any excess fails the named budget gate.
  • Requirements: 1.4, 6.1, 6.2, 6.3, 6.4

• 11.4 Run the full migration, security, and regression gate

  • Verify core imports only standard-library and lower core layers and contains no target, DSPy, benchmark, proof-execution, or analyzer dependencies.
  • Run all unit, adapter, migration, reference-family, end-to-end, admission, and historical compatibility suites.
  • Enforce function/module complexity caps and scan for remaining v1 imports or writers.
  • Prove each test instrument read nonzero fixture bytes before interpreting zero findings or failures.
  • Done when the complete suite passes, boundary/import censuses are clean, historical bytes are unchanged, and all declared adapter and consumer seams pass conformance.
  • Requirements: 1.4, 10.4, 14.3, 15.3, 15.4
  • Depends: 10.7

Implementation Notes

• The frozen migration inventory is a reviewed worklist with stable identities, not a semantic-use census. It may only close entries as v2_migrated or retired; it never grows, deletes entries, or proves absence by interpreting Python flow.
• Cutover is proved by explicit syntax checks plus deletion of the compatibility and v1 write capability. No task extends the discarded alias/data-flow interpreter.
• Task 10.5 debug established that executable owner probes cannot compensate for blanket source-closure acceptance; resumed hunt attempts also require collision-resistant attempt identity and create-only persistence before handoff validation is authoritative.
• Human review reopened Task 10.5 for one focused remediation cycle covering exact source-closure evidence, collision-resistant create-only attempt persistence, and complexity-cap conformance.