Implementation Plan

Completed baseline

The completed work below produced the immutable 2026-10-28 development baseline. Amendment tasks 7-13 replace its final resolution, dominance, fact-acquisition and measurement semantics without erasing the evidence.

1. Baseline paths and checker premise
1.1 Add bounded caller-index paths with concrete hop records
- Delivered depth/fan-out traversal, entry stopping, file-qualified hops and unreached targets.
- Baseline fixtures cover depth, fan-out, deduplication and multiple same-name files.
- The final call semantics are superseded by tasks 8-9.
- Requirements: 3.1, 3.9, 3.10
- Boundary: Concrete Paths
1.2 Add the opt-in recognised-entry-is-protected premise
- Existing checker defaults remain unchanged; prover evidence identifies the premise.
- Requirements: 4.6
- Boundary: Obligation Checker
2. Baseline entry recognition
2.1 Add the first Java entry recognisers and evidence
- Delivered development cases for declared web methods, servlets, resources and handlers.
- Requirements: 1.1, 1.5
- Boundary: Mapping
2.2 Add the initial PHP, JavaScript, TypeScript and Python entry recognisers
- Delivered positive and negative fixture coverage with entry evidence.
- Requirements: 1.1, 1.5
- Boundary: Mapping
3. Baseline enforcement and operation facts
3.1 Add route-, declaration- and policy-scoped enforcement witnesses
- Delivered initial external-handler witnesses and integration fixtures.
- Requirements: 2.2, 2.4
- Boundary: Enforcement Adapter
3.2 Close the unfinished per-target fact inventory as superseded
- The partially completed inventory is not treated as complete implementation.
- Tasks 11.3-11.7 replace it with label-blind acquisition and promoted target knowledge.
- Requirements: 2.1, 2.2, 2.9, 2.10
- Boundary: Target Knowledge
3.3 Add handler-named operation facts
- Delivered opt-in handler operations at declaration lines for recognised entries.
- Requirements: 2.3
- Boundary: Fact Interpreter
4. Baseline prover, traces and structural control flow
4.1 Integrate entries, paths, operations and witnesses in the deterministic prover
- Delivered hunt-defect findings and failure-visible baseline coverage with no model calls.
- Final three-way judgment is superseded by task 10.6.
- Requirements: 4.7
- Boundary: Prover Integration
4.2 Emit deterministic ordered traces and local argument provenance
- Delivered canonical text/JSON traces for discharged and unguarded baseline pairs.
- Requirements: 9.1, 9.2, 9.3, 9.5
- Boundary: Canonical Trace
4.3 Attach traces to prover records and findings
- Delivered trace references through the replay envelope.
- Requirements: 8.1, 9.7
- Boundary: Prover Integration
4.4 Build structural control-flow graphs
- Delivered branches, loops, exits, exception regions, dominators and control context.
- Requirements: 10.1, 10.2, 10.3, 10.4
- Boundary: Structural CFG
4.5 Add baseline CFG dominance and guard effects
- Delivered value-only rejection and control-context trace fields.
- Strict unknown semantics are superseded by task 10.1.
- Requirements: 10.1, 10.2, 10.3, 10.4, 10.5
- Boundary: CFG Dominance
5. Baseline replay arm
- Delivered checkpointed records, standard metrics, coverage tables, zero-byte refusal and immutable records.
- Requirements: 5.1, 5.2, 5.4, 5.6
- Boundary: Development Runner
6. Baseline development measurement
- Measured 23 repositories and 483 changes: 65.2% fix-push recall, 15.0 flagged ordinary pushes per 100, 0 instrument failures; recorded at benchmarks/measurements/2026-10-28-access-control-prover/.
- The population is development evidence only and remains immutable.
- Requirements: 5.2, 5.7, 12.9
- Boundary: Development Measurement

Amendment implementation

7. Abstract evidence foundation
7.1 Implement the evidence-relation algebra and completeness value
- Encode the specified precision order, complete join table, dimension conjunction and witness aggregation.
- Preserve every incompleteness reason deterministically and deduplicate reasons without losing stage identity.
- Done when exhaustive table tests and algebraic law tests pass for every relation pair.
- Requirements: 11.1, 11.6, 11.7
- Boundary: Abstract Evidence Domain
7.2 Add resource abstract values and operation-fact fields
- Represent exact resources, finite alias sets, request-global scope and unknown resources.
- Extend operation facts to state when a request-global guard is sufficient.
- Done when resource parsing and joins distinguish exact, alias, global and unknown fixtures.
- Requirements: 2.1, 2.5, 2.6, 2.7, 11.1
- Boundary: Resource Domain
- Depends: 7.1
7.3 Add authority abstract values and promoted implication facts
- Represent exact, finite and unknown authorities separately from resources.
- Load authority implications from promoted facts and retain the supporting fact identifier.
- Done when sufficient, insufficient and unknown authority fixtures produce the specified relations.
- Requirements: 2.1, 2.2, 2.5, 2.7, 2.8, 11.1
- Boundary: Authority Domain
- Depends: 7.1
7.4 Extend judgment, trace and coverage contracts with abstract state
- Add three-way judgments, completeness and evidence relations without changing legacy defaults.
- Add canonical serialization for resource and authority relations and all incompleteness reasons.
- Done when old trace fixtures remain stable in legacy mode and new fixtures round-trip all abstract fields.
- Requirements: 7.1, 7.2, 7.5, 7.6, 9.1, 9.2, 9.6
- Boundary: Judgment Contracts, Canonical Trace
- Depends: 7.1, 7.2, 7.3
8. Stable symbols and conservative call resolution
8.1 Capture call receiver and arity evidence in the semantic IR
- Preserve receiver expression and argument count for supported syntax while keeping existing constructors valid.
- Done when language fixtures retain receiver and arity evidence without regressing existing IR consumers.
- Requirements: 3.2, 3.3
- Boundary: Semantic IR
8.2 Build stable declaration identities and the per-change symbol index
- Identify declarations by module, enclosing type, name and available signature.
- Cache the symbol and inheritance indexes on the per-change context.
- Done when duplicate type names, same-name methods and overloads receive stable distinct identities.
- Requirements: 3.2, 3.5, 6.2
- Boundary: Symbol Index
- Depends: 8.1
8.3 Resolve exact, finite-candidate and unresolved call targets
- Return complete exact targets, incomplete finite candidate sets, or unresolved results with reasons.
- Remove global bare-name fallback from prover-mode resolution.
- Done when ambiguity never merges methods and unresolved calls cannot produce complete paths.
- Requirements: 3.3, 3.4, 11.1, 11.6
- Boundary: Call Resolution
- Depends: 8.2
8.4 Resolve inheritance and base-declaration attachment
- Attach base operations and entries only through repository-defined descendant relations.
- Preserve ambiguous inheritance as incomplete rather than projecting to unrelated routes.
- Done when subclass and unrelated-class fixtures produce distinct attachments and judgments.
- Requirements: 3.5
- Boundary: Call Resolution
- Depends: 8.2, 8.3
9. Interprocedural summaries and concrete paths
9.1 Extract local function summaries
- Collect each function's operations, witnesses, resolved calls and local completeness without traversing callers.
- Done when summaries are deterministic and contain no target names outside fact identifiers.
- Requirements: 3.1, 3.6, 11.7
- Boundary: Function Summaries
- Depends: 7.4, 8.3
9.2 Compute monotone summaries over recursive call components
- Iterate finite summary sets over strongly connected components until stable.
- Done when direct recursion and mutual recursion terminate with stable accumulated evidence.
- Requirements: 3.7, 11.6
- Boundary: Function Summaries
- Depends: 9.1
9.3 Add summary caches and explicit exploration cutoffs
- Reuse summaries per change and carry depth, fan-out, deadline and other cutoff reasons into completeness.
- Done when each cutoff fixture returns accumulated evidence plus the exact incomplete reason.
- Requirements: 3.8, 6.2, 6.3, 7.2
- Boundary: Function Summaries, Context Cache
- Depends: 9.2
9.4 Materialise exact evidence paths from summaries
- Emit concrete entry-to-operation hops only through exact target edges.
- Preserve every complete chain independently and retain candidate-edge diagnostics separately.
- Done when guarded and unguarded paths to one operation remain separate and candidate edges never complete a path.
- Requirements: 3.9, 3.10, 11.4, 11.5
- Boundary: Concrete Paths
- Depends: 9.3
10. Strict authorization judgment
10.1 Return abstract dominance relations without prover fallback
- Return MUST, MAY, NO or UNKNOWN with guard effect and control context.
- Keep legacy order dominance unchanged, but return UNKNOWN in prover mode for unavailable graphs or line mappings.
- Done when no prover fixture is discharged or flagged solely through textual-order fallback.
- Requirements: 10.1, 10.2, 10.3, 10.4, 10.5, 10.6, 10.7
- Boundary: CFG Dominance
- Depends: 7.1
10.2 Match witness kind, scope and resource
- Apply request-global sufficiency only when the operation fact declares it.
- Return NO for definite mismatch and UNKNOWN for unresolved resource compatibility.
- Done when same-resource, alias, global, mismatch and unknown fixtures match the design algebra.
- Requirements: 2.1, 2.2, 2.5, 2.6, 2.7, 11.1
- Boundary: Witness Matcher
- Depends: 7.2, 10.1
10.3 Match authority and promoted implications
- Apply only promoted authority implications and preserve their evidence.
- Return NO for insufficient authority and UNKNOWN when compatibility cannot be decided.
- Done when stronger, weaker, unrelated and unknown authorities produce the expected relations.
- Requirements: 2.2, 2.5, 2.7, 2.8, 11.1
- Boundary: Witness Matcher
- Depends: 7.3, 10.1
10.4 Compute one judgment per complete or diagnostic path
- Conjoin witness dimensions, aggregate witnesses per obligation and apply the mixed-obligation rule.
- Emit discharged only for all-MUST, indeterminate for any MAY/UNKNOWN, and unguarded for at least one NO.
- Done when MUST/NO, MAY/NO, UNKNOWN and empty-witness fixtures match the specified truth table.
- Requirements: 4.1, 4.2, 4.3, 11.2, 11.3, 11.4
- Boundary: Pair Judgment
- Depends: 10.2, 10.3
10.5 Aggregate multiple paths in the opt-in checker mode
- Return unguarded if any complete path is unguarded, discharged only for complete all-discharged enumeration, and indeterminate otherwise.
- Keep the legacy checker API and defaults unchanged.
- Done when mixed guarded, unguarded and incomplete path sets produce the specified aggregate.
- Requirements: 3.10, 4.1, 4.2, 4.3, 4.4, 4.5, 11.5
- Boundary: Obligation Checker
- Depends: 9.4, 10.4
10.6 Integrate three-way judgments into the prover
- Emit hunt findings only for unguarded pairs and send no indeterminate pair to the proof arm.
- Carry all judgments, completeness reasons, resources, authorities and stable identifiers in traces and coverage.
- Record stage-specific exceptions without folding them into quiet coverage.
- Done when end-to-end fixtures distinguish unguarded, discharged and indeterminate records and findings.
- Requirements: 4.4, 4.5, 4.6, 4.7, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 8.1, 8.2, 8.3, 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7
- Boundary: Prover Integration, Canonical Trace
- Depends: 7.4, 9.4, 10.5
11. Target knowledge registry and acquisition
11.1 (P) Add the entry-recognition strategy registry
- Route mapping dispatch through one registry without embedding target names in engine modules.
- Done when a fixture strategy registers, runs and records its strategy identifier and evidence.
- Requirements: 1.1, 1.5, 1.7
- Boundary: Mapping Registry
- Depends: 7.1
11.2 Add the generic call-site registration strategy
- Resolve repository-defined registered handlers through stable symbols and return unresolved registration coverage.
- Done when exact and unresolved registration fixtures produce entries or coverage respectively.
- Requirements: 1.2, 1.3, 1.4, 1.5, 1.6
- Boundary: Registration Adapter
- Depends: 8.4, 11.1
11.3 (P) Extract existing target knowledge into candidate records
- Read legacy recognition strategies and current facts without changing promoted outputs.
- Done when extraction produces deterministic candidate records with source/version/region evidence.
- Requirements: 2.9
- Boundary: Fact Initialization
- Depends: 7.1
11.4 Verify and promote proposed target knowledge
- Accept source- or approved-documentation proposals, reject contradictions, and write only verified outputs.
- Done when matching proposals promote and contradicted or evidence-free proposals leave promoted knowledge unchanged.
- Requirements: 2.9, 2.10
- Boundary: Fact Initialization
- Depends: 11.3
11.5 Record acquisition provenance and enforce label-isolated mode
- Persist input revision, evidence digest, accepted/rejected proposals and output digest.
- Reject admission acquisition inputs containing vulnerability, fix-location or ordinary-change labels.
- Done when changed output after labels are opened marks the population spent.
- Requirements: 12.1, 12.2, 12.3
- Boundary: Fact Initialization, Admission Guard
- Depends: 11.4
11.6 Migrate one legacy recogniser through the registry
- Move one development-evidence family out of inline dispatch without changing its entries.
- Done when old fixtures stay stable and inline target-specific matching is removed for that family.
- Requirements: 1.1, 1.7
- Boundary: Mapping Registry
- Depends: 11.1
11.7 Run the first label-blind development acquisition
- Produce registration, handler-operation, enforcement, resource and authority knowledge through the gate.
- Treat the output as development data and record its acquisition digest; do not encode names in engine modules.
- Done when promoted outputs load, rejected proposals have reasons, and the old unfinished task 3.2 has no residue.
- Requirements: 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9, 2.10, 5.7, 12.9
- Boundary: Target Knowledge
- Depends: 10.3, 11.2, 11.5, 11.6
12. Development and admission runners
12.1 Materialise and verify baseline and candidate analyzer bundles
- Resolve analyzer revisions, fact sets, acquisition records and configurations to immutable digest-verified inputs.
- Refuse comparison when any bundle artifact is unavailable or mismatched.
- Done when the immutable baseline and a fixture candidate bundle can be reconstructed exactly.
- Requirements: 5.1, 5.5, 12.1
- Boundary: Run Manifests
12.2 Add record provenance, stage funnel and judgment transitions
- Persist analyzer, fact, acquisition, configuration, population and input digests per record.
- Summarise every analysis stage, completeness reason and transition between compared judgments.
- Done when a fixture run accounts for every record from entry recognition through final judgment.
- Requirements: 5.1, 5.3, 5.4, 7.1, 7.6, 9.7, 11.8
- Boundary: Development Runner
- Depends: 10.6, 12.1
12.3 Enforce instrument and hard runtime gates
- Preserve zero-byte and stale-anchor refusal and add stage-aware deadline records.
- Fail the run if any measured change exceeds 120 seconds; never summarize the overrun as a passing result.
- Done when zero-byte, stale-anchor, deadline and 121-second fixtures all refuse the summary.
- Requirements: 5.6, 6.1, 6.3
- Boundary: Runner Gates
- Depends: 12.2
12.4 Register the four-arm development comparison
- Run baseline/candidate analyzer crossed with baseline/candidate facts over identical inputs.
- Report metric deltas, stage-funnel deltas and judgment transitions without admission language.
- Done when fixture arms isolate a fact-only lift from an analyzer-only lift.
- Requirements: 5.2, 5.5, 5.7, 11.8
- Boundary: Development Runner
- Depends: 12.1, 12.2, 12.3
12.5 Consume and validate an externally reviewed admission manifest
- Accept only a manifest produced by valid-detection-benchmark with review, isolation and immutable digest fields.
- Reject label exposure, changed acquisition output or a spent population.
- Done when valid, malformed, exposed and spent manifests produce deterministic accept/refuse results.
- Requirements: 12.1, 12.2, 12.3, 12.6, 12.8
- Boundary: Admission Runner
- Depends: 11.5, 12.3
12.6 Add paired scoring and the admission report
- Score vulnerable/fixed twins, reviewed ordinary changes, indeterminate rate, coverage, runtime and instruments.
- Preserve sample counts and uncertainty intervals and return NO-GO on any pre-registered gate failure.
- Done when fixture pairs detect vulnerable-only, fixed-side regression and mislabeled-negative cases.
- Requirements: 5.2, 12.4, 12.5, 12.7, 12.8, 12.9
- Boundary: Admission Runner
- Depends: 12.5
13. Cross-cutting validation and measurements
13.1 Validate abstract-domain and metamorphic laws
- Cover the full join table, conjunction, witness aggregation, monotonicity and mixed-obligation rule.
- Prove that type renaming preserves a judgment and adding ambiguity can only preserve it or make it indeterminate.
- Done when property and fixture tests pass deterministically across repeated runs.
- Requirements: 11.2, 11.3, 11.4, 11.5, 11.6, 11.7
- Boundary: Abstract Evidence Validation
- Depends: 10.5
13.2 (P) Validate cross-component analysis scenarios
- Exercise helper guards, registration entries, base attachment, resource mismatch, authority insufficiency, ambiguous calls, unavailable CFGs, recursion and budget cutoff.
- Done when every scenario yields the expected trace, coverage reasons and three-way judgment.
- Requirements: 1.1, 1.2, 1.3, 2.1, 2.2, 2.5, 2.7, 3.4, 3.5, 3.6, 3.7, 3.8, 4.1, 4.2, 4.3, 10.6
- Boundary: Prover Integration Validation
- Depends: 10.6, 11.7
13.3 Run the four-arm development regression
- Run all four registered arms on the immutable current development population after proving nonzero input reads.
- Publish analyzer/fact attribution, stage funnel, three-way judgments, budget result and comparison to the 2026-10-28 baseline; label the result development-only.
- Done when all arm records and summary digests are complete and no admission claim appears.
- Requirements: 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7, 6.1, 7.3, 11.8, 12.9
- Boundary: Development Measurement
- Depends: 12.4, 13.1, 13.2
13.4 Run admission from an externally prepared untouched manifest
- Consume a reviewed manifest from valid-detection-benchmark after analyzer and facts are frozen.
- Verify label isolation, paired vulnerable/fixed behavior, reviewed ordinary labels and every admission gate.
- Done when the report returns an evidence-backed GO or NO-GO without modifying facts, strategies or thresholds.
- Requirements: 12.1, 12.2, 12.3, 12.4, 12.5, 12.6, 12.7, 12.8, 12.9
- Boundary: Admission Measurement
- Depends: 12.6, 13.3
14. Reviewed detection-core fact adapter
14.1 Define the production access-control family contract
- Encode the versioned access-control security object, roles, three decision rules, residual question and closed incompleteness reasons through public detection-core types.
- Keep target names outside the contract while pinning every digest-affecting field, status, origin policy and ecosystem declared by the design.
- Done when the canonical production contract validates, round-trips deterministically, and rejects every altered or undeclared role, decision, field and reason fixture.
- Requirements: 13.1
- Boundary: Access-Control Family Contract
- Depends: 11.5
14.2 Implement externally bootstrapped fact authority
- Define the immutable authority bundle and separate host bootstrap policy over reviewed pack/projection references, policies, lineages, matcher identity, reviewer/store admission, forbidden identity pairs and conflict disclosure.
- Re-derive canonical policy, attestation, disclosure and bundle identities before any target data is consumed; never let the bundle choose its own trust roots.
- Done when a complete independently reviewed authority fixture authenticates and every missing, duplicate, substituted, self-authored or non-canonical variant fails before pack loading.
- Requirements: 13.2, 13.3
- Boundary: Fact Authority
- Depends: 14.1
14.3 Migrate the installed entry knowledge into reviewed v2 packs
- Produce one language-scoped v2 pack per promoted language and a separately authenticated canonical compatibility projection from the existing reviewed entry data.
- Map every migrated row to declared roles, typed structural requirements and relation effects without adding target vocabulary to engine modules.
- Preserve legacy pattern recognition byte-for-byte while preventing the projection from constructing detection-core evidence or readiness.
- Done when legacy recognition fixtures are unchanged, both reviewed language packs validate under task 14.2 authority, and projection-only input remains non-authoritative.
- Requirements: 1.1, 1.5, 1.7, 2.9, 2.10, 13.2, 13.4
- Boundary: Entry Knowledge Migration
- Depends: 14.1, 14.2
14.4 Add canonical structural-observation and fact-match persistence
- Provide the downstream write boundary that persists canonical StructuralObservation bytes and returns immutable references through a read-only resolver.
- Persist completed fact_match_bytes only after its observation references exist, then return the match reference without inserting a circular self-reference into the match digest.
- Done when stored observation and match bytes resolve canonically and byte or reference substitution is refused deterministically.
- Requirements: 13.5
- Boundary: Fact-Match Artifact Writer
14.5 Implement the authority-bearing structural matcher
- Build typed observations from repository structure for the requirements declared by the selected reviewed fact; do not infer missing structure from a regex or name hit.
- Use task 14.4 to persist every observation and completed FactMatchEvidence, then pass the immutable match reference with family contract, policies, lineages, custody and read-only resolver to detection-core.
- Bind matcher behavior and fact lineage to current custody and the evaluation population so same-population label influence is incomplete or refused.
- Done when complete fixtures apply the declared relations, while name-only, partial, ambiguous, substituted and contaminated fixtures cannot produce complete evidence.
- Requirements: 1.1, 1.2, 1.3, 1.5, 7.2, 9.4, 13.5, 13.6
- Boundary: Structural Matcher
- Depends: 14.2, 14.3, 14.4
14.6 Produce the downstream conformance handoff
- Run detection-core fact-pack, fact-match, application and full-evidence validators over target-owned fixtures after proving nonzero fixture reads.
- Publish an immutable manifest naming every fixture, artifact digest, validator result and negative-case reason for detection-core task 9.4 to accept; do not add target fixtures to core.
- Exercise authority substitution, producer/reviewer conflict, resolver byte substitution, lineage omission, custody contamination and deterministic replay.
- Done when the complete target-owned fixture passes, every incomplete/self-authored/substituted/contaminated/legacy-only variant is refused with a stable reason, and the immutable handoff manifest is reproducible.
- Requirements: 7.2, 7.4, 12.2, 12.3, 13.7
- Boundary: Downstream Adapter Conformance Handoff
- Depends: 14.5
14.7 Migrate the production entry caller and prove zero bypasses
- Wire the externally bootstrapped authority-bearing adapter into the target-aware mapping/legacy.py entry path while keeping analyze_entry_points stable for its callers.
- Retain the legacy projection only for compatibility recognition; prohibit it from supplying v2 evidence, readiness or admission.
- Run import/caller and artifact-writer censuses proving no production path bypasses authority or treats legacy projection output as v2 evidence.
- Done when existing entry recognition remains byte-stable, explicit v2 matching uses the reviewed persisted path, and both production bypass censuses are zero.
- Requirements: 1.1, 1.5, 1.7, 13.4, 13.7, 13.8
- Boundary: Production Mapping Integration
- Depends: 14.6
- Blocked: detection-core task 9.4 must accept the immutable handoff from task 14.6 before production caller migration

Task constraints

Complexity: McCabe at most 10 per touched function, at most 50 logical lines per function and 400 per new module.
Engine/target split: abstract-domain, resolution, summary, judgment and trace modules contain no target names.
Target knowledge: names enter only through promoted facts or registered target-aware strategies.
Compatibility: legacy checker defaults and completed baseline records remain unchanged.
Instrument rule: validation must prove nonzero input reads before interpreting any clean or zero result.

Baseline implementation record

Deliveries A-C implemented the baseline paths, recognisers, witnesses, handler facts, prover, traces and CFG with static checks and focused tests passing at delivery time.
The full development arm then processed all 483 changes with zero instrument failures. Its maximum runtime exceeded the amended hard budget, so the baseline is evidence, not an eligible arm.
The 2026-10-28 ablation identified call resolution, resource/authority precision and failure visibility as the amendment levers. Those observations inform tasks 7-13 but are not admission labels.

26 KiB Raw Blame History

Implementation Plan

Completed baseline

Amendment implementation

Task constraints

Baseline implementation record

26 KiB

Raw Blame History