Repository navigation
The roadmap calls B3, C1, C3 and the compatibility policy blocked by research; the research delivered and accepted them #34
Description
Found by the review of 2026-09-25 while reconciling the roadmap with the research registry.
ROADMAP.md ("Who blocks what") says target B3 waits for PV-HIST-001, C1 for GitLab adapter requirements, C3 for PV-INSTR-001 and its children, the compatibility policy for a contract that defines a breaking change, and it lists four judgements the research process still owes this repository. The registry says every one of those was produced, independently reviewed and accepted between 2026-09-06 and 2026-09-17. The blocker is now this repository, and the roadmap should say so.
| Roadmap item | Unit | Verdict | What was accepted |
|---|---|---|---|
| B3 durable revision history | PV-HIST-002 |
ACCEPTED by PV-REV-HIST-002 (2026-09-08) |
the cumulative durable cross-bundle Integrity revision-history contract: prior UNKNOWN_HISTORY / HISTORY_GAP cannot heal into a favourable verdict, policy provenance, replay-or-INCOMPARABLE on semantic change. Closes the HISTORY_PROVENANCE_PARENT_LEVEL_ONLY gap the roadmap describes |
| C1 GitLab adapter | PV-GITLAB-003 |
ACCEPTED by PV-REV-GITLAB-003 |
the provider-neutral GitLab adapter requirements (cumulative through PV-GITLAB-001..003): instance plus numeric project identity, merge requests, iteration lifecycle encoding, pipelines with in-place retries under the accepted CI semantics, exact rational Flow timing |
| C3 Instruments | PV-REV-INSTR-001, PV-INSTR-CARRIER-002 (accepted by PV-REV-INSTR-CARRIER-002), PV-COV-003 (PV-REV-COV-003), PV-TESTSTATE-002 (PV-REV-TESTSTATE-002), PV-DEPLOY-002 (PV-REV-DEPLOY-002), PV-WORK-002 (PV-REV-WORK-002) |
all ACCEPTED | the instrument envelope (devostasis.instrument-envelope.v1, INSTR-01..14), the carrier that integrates instruments into config, effective config, bundle, report and history (devostasis.config.v2, devostasis.effective-config.v3, instruments.json), and four instrument contracts: coverage (COV-01..26), test state (TSTATE-01..), deployment state (DEPLOY-01..), work activity (WORK-01..36) |
| Versioning and compatibility policy | PV-COMPAT-002 |
ACCEPTED by PV-REV-COMPAT-002 |
devostasis.contract-compatibility.v1: version-bearing identifiers are opaque exact tokens, verification dispatches only under an immutable versioned dispatch policy with its own identity; no suffix, nearest or latest inference. This is the "what is a breaking change" contract the roadmap says does not exist |
| B1 vectors, the families v1 cannot carry | PV-CONFORMANCE-SURFACE-001 |
ACCEPTED by PV-REV-CONFORMANCE-SURFACE-001 |
devostasis.executable-conformance-surface.v1: the minimum implementation-neutral successor boundaries for R5..R10 provider-native normalization, T3's RAW_RUNS provenance, T6, T8 and the bundle and store cases (#20, #23) |
| Renderer themes | PV-RENDER-CLINICAL-001 |
ACCEPTED_TECHNICAL_CONTRACT by PV-REV-RENDER-CLINICAL-001 |
devostasis.render.theme.clinical.v1, a finite deterministic presentation theme separate from machine semantics; the owner-selected vocabulary per band is still the open input |
| Calibration corpus | PV-SYNTHETIC-ARCHETYPES-001 |
ACCEPTED by PV-REV-SYNTHETIC-ARCHETYPES-001 |
the three missing project archetypes (blocked external dependency, under-documented, highly mature) as fixture contexts; with them the nine-archetype synthetic completion gate is closed on the research side |
| Judgements owed to us | PV-REV-REGISTERS-001 ACCEPT, PV-REV-FLEET-001 ACCEPT, PV-REV-DIRECTION-CLOSED-TARGET-001 REPAIR REQUIRED, PV-SPEC-001 twice on 2026-09-07 |
delivered | registers and the Target: marker satisfy G7; devostasis.fleet.v1 with aggregate and cross_project_order null is the accepted design (FLEET-01..10); finding 9 is a required Direction repair (tracked with the other Vital repairs); the post-repair PV-SPEC-001 pass found the runtime conformant and the public status prose stale, which #31 reconciles |
What this issue asks for:
- The roadmap rows above move from "blocked by research" to "ours"; Adopt every delivered research judgement and repair the review findings (0.1.9) #31 does that.
- A sequencing decision by the owner: the accepted Phase C material (GitLab, instruments, carrier) is large and changes the configuration and bundle contracts (
config.v2,effective-config.v3, a new required member), so it belongs after B7 and after the compatibility policy is implemented, in that order, because the policy is what makes such a move safe for an adopter. B3 (PV-HIST-002) can go earlier: it changes Integrity's history source, not the consumer surface. - Until each unit is adopted, the 0.2 condition "no accepted research unit is waiting for adoption" is not met, and the roadmap should count them rather than the four it lists.
Sources: the research registry (UNIT_REGISTRY) and the accepted documents in the owner's Drive mirror; the handoff document (ANSWERS_TO_IMPLEMENTER) carries the implementation notes for each.
Activity
Reconcile the roadmap with what the research process delivered
drevendev commentedon Sep 30, 2026
B3 is adopted in #53 (0.2.0):
PV-HIST-002underintegrity.bands.v1+ci-unit-004+hist-002, with the carrierci.revision_history_carriedin andderived.revision_historyout, HIST-01..20 executable except HIST-14 (no accepted migration exists to execute). The first 0.2.0 bundle of a project replays its 0.1.9 predecessor's revision records as lineagedevostasis.ci-history.v1.Two consequences went to their own issues: #52 (for the research side: R52 leaves Integrity permanently
UNKNOWNfor repositories verified only by external check apps) and #51 (the busiest fleet repository hits the provider's run-listing cap). Still open here:PV-REV-GITLAB-003, the instrument contracts,PV-COMPAT-002,PV-CONFORMANCE-SURFACE-001,PV-RENDER-CLINICAL-001, sequenced after B7 and the compatibility policy.🤖 Generated with Claude Code
abogun-product commentedon Oct 6, 2026
PR #64 adopts the accepted exact-token compatibility policy (PV-COMPAT-001/002), including complete bundle tuple admission, source validation before projection, operation-scoped asymmetric/nontransitive edges, immutable finite dispatch policy identity/digest, pinned replay and ambiguity failure (COMPAT-21/22). No production nonidentity edge or migration is declared.
The same release adopts cumulative PV-RECEIPT-IDENTITY-003 and preserves frozen historical core/work verification. This closes the compatibility implementation portion of this issue; it does not claim the core Phase C GitLab/Instrument carrier, B1's remaining research vectors or B7's sustained calibration. The roadmap/provenance explicitly distinguish accepted research, adopted implementation and deployment evidence.