AGENTIC DEVELOPMENT ORCHESTRATOR
A coding system that can challenge its own work.
Agentic Development Orchestrator is a governed engineering loop that binds implementation, a separate read-only audit role, evidence, remediation, and approval to exact review snapshots. It aims to remove unnecessary workflow interruption while keeping human authority, stop conditions, rollback, and evidence explicit.
Stable evidence snapshot: 31 August 2026
- ReviewsTen distinct Review packages in the stable snapshot
Repository-derived values from one stable snapshot. These figures are evidence history, not a quality score.
The governed loop
Eight named states from owner mandate through implementation, pinned review, read-only audit, remediation, decision, evidence, and promotion or stop, with a mandatory verification round, a dashed owner-escalation branch, a stop branch with manual fallback retained, and dotted record links into the evidence node. Each node is a button: hover, focus, or tap for its role, trigger, input, action, output, authority basis, prohibited actions, failure behavior, and current status.
- Operational in stable evidence
- Operational foundation; automatic approval in implementation · dashed ring
- Future direction · not in this loop
- Authority
- Engineering
- Assurance
- Evidence
- Trigger
- A pinned review snapshot is presented.
- Input
- The exact pinned review snapshot.
- Action
- Inspects the snapshot, runs read-only analysis, reports findings, and issues a verdict.
- Output
- Audit report and verdict.
- Authority basis
- A separate system role. It is not a third-party certification or independent assurance firm.
- Prohibited
- Cannot implement, widen scope, approve, or authorize continuation.
- Failure behavior
- Stops on unverifiable identity or evidence and records NOT_AUDITABLE rather than a clean result.
- Loop state
- Auditing
Operational in stable evidence
Reviews the exact pinned snapshot and produces a report and verdict. It cannot implement, widen scope, authorize continuation, or silently convert unknown evidence into approval.
02 · THE LOOP
One change becomes a traceable loop.
A change is not treated as complete when code exists. It moves through an implementation handoff, a pinned review snapshot, a separate audit, a recorded response, a mandatory verification round, and an explicit approval or escalation path.
Every consequential transition should leave a durable artifact. The system is designed so that a later reviewer can ask what was authorized, which exact tree was examined, what was found, what changed, and why continuation was permitted.
The product is not only the code. The product is also the trace that explains why the code was allowed to move.
Workflow outcomes
- Continue within authority
- Remediate and verify
- Escalate to owner
- Stop on unverifiable state
- Retain manual fallback
- Active route
- Other branches
- Durable output
- Operational foundation; automatic approval in implementation
- Retained fallback
The diagram is an explanatory model of the governed workflow. Current implementation status is shown separately and must not be inferred from animation alone.
Governed workflow explorer
Thirteen workflow stages from mission and work package to promotion, escalation, or manual fallback, laid out as a serpentine with every branch visible. The Normal governed completion route is emphasised. Each stage shows its durable output; implementation status is a separate field.
Operational in stable evidence
Reviews the exact pinned snapshot and produces a report and verdict. It cannot implement, widen scope, authorize continuation, or silently convert unknown evidence into approval.
- Route
- Normal governed completion
- Trigger
- Audit directive for a pinned snapshot.
- Input
- The exact pinned review snapshot.
- Action
- Inspects the snapshot with read-only analysis and reports findings.
- Durable output
- Audit report draft.
- State before
- Audit requested.
- State after
- Auditing.
- Stop condition
- Unverifiable identity or evidence; the report records NOT_AUDITABLE.
- Next on this route
- 06 · Committed report and evidence witness
Basis: Current status · As of 31 August 2026
03 · AUDITED SURFACE
The attested audit surface grew from 81 to 329 paths.
The first measurable audit report recorded 81 attested paths. The latest report in the stable snapshot recorded 329. Across the sequence, the audit surface expanded as the system accumulated workflow controls, evidence handling, recovery logic, orchestration, and governance.
4.06× larger attested surface
- First measurable report81
- Latest report329
- Canonical reports21
- Stable repository files299
Report in view
- ReportR10.2 · Review 10
- Date30 Aug 2026
- Attested paths329
- Findings8 · 4 HIGH · 4 MEDIUM
- Recorded duration17m 45s
- VerdictChanges required
- Round 1
- Round 2
- Historical Round 3
- Historical Round 3 · dashed link off the series
- Not recorded · NOT_AUDITABLE
Recorded attested path count by audit report
Ordered sequence of 21 audit reports on the horizontal axis with the audit File Count recorded by each report on the vertical axis, from 0 to 350. First measurable File Count 81 at R01.2; latest 329 at R10.2; derived change 4.06×. R01.1 is NOT_AUDITABLE with no recorded File Count and is drawn as an explicit missing mark at the baseline, not as zero. Round 1 and Round 2 are filled marks joined by a solid line; the historical Round 3 report is an outlined diamond linked to its neighbours by a dashed path. Mark size scales with the findings total. The stable repository file count of 299 is a different measure and is shown only as a separate note, not on the axis.
Use Left and Right arrow keys to move between reports, Home and End to jump to the first and last report, Enter or Space to pin a report, and Escape to clear the pin.
- Date
- 30 Aug 2026
- Round
- Round 2
- File Count
- 329
- Findings
- 8
- HIGH · MEDIUM
- 4 · 4
- Recorded duration
- 17m 45s
- Verdict
- Changes required
- Recorded disposition
- 8 fixed · 0 accepted risk · 0 owner decision
Latest report in the stable snapshot.
04 · TWO ROUNDS
The second round challenged the first again.
For Reviews 02 through 10, Round 1 recorded 62 findings and Round 2 recorded 52. Most review pairs stayed level or declined, but one review increased from 8 findings to 12.
The second round is not a ceremonial sign-off. It can expose new defects, incomplete remediation, regressions, and adjacent risks.
Current values
- ReviewAll nine paired reviews
- MeasurePaired findings
- Round 162
- Round 252
- Difference−10
- Directiondecreased
Highlighted exception: Review 04 increased from 8 findings in Round 1 to 12 in Round 2.
Aggregate · Round 1 → Round 2
- Paired findings62 → 52
- HIGH32 → 24
- MEDIUM30 → 28
The difference between rounds is descriptive. It is not a controlled measure of code quality, remediation effectiveness, or audit difficulty.
Review 01 predates the later two-round ceiling and includes a third historical round. Its first record was NOT_AUDITABLE, so it is presented separately and excluded from the paired comparison.
- R01.1 · Round 1NOT_AUDITABLE
- R01.2 · Round 22 findings
- R01.3 · Historical Round 32 findings
Round 1 and Round 2 recorded findings, Review 02 to Review 10
For Reviews 02 through 10, Round 1 recorded 62 findings and Round 2 recorded 52. Most review pairs stayed level or declined, but one review increased from 8 findings to 12. Review 04 increased from 8 findings in Round 1 to 12 in Round 2. The chart is a slopegraph: two columns show each review's Round 1 value on the left and Round 2 value on the right, joined by a straight line. A falling line marks a decrease, a rising line an increase, and a level line no change. Review 04 is drawn heavier and annotated. The aggregate for all nine paired reviews is drawn separately above the reviews on its own scale.
- Round 1
- Round 2
- Highlighted exception
- Round 1
- 62
- Round 2
- 52
- Absolute difference
- −10
- Direction
- decreased
05 · AUDIT ATLAS
118 findings stayed visible, by severity and round.
The stable evidence history contains 56 HIGH and 62 MEDIUM findings across 21 reports. No finding was recorded as CRITICAL in this snapshot.
- Reports21
- Recorded findings118
- CRITICAL0
- HIGH56
- MEDIUM62
Finding count measures what the audits recorded. It is not a defect density, risk score, or comparison with another project.
Select a review, round, or severity to see the same evidence reorganized without losing the total context.
Visible 118 of 118 recorded findings · Stable total 118 across 21 reports ·
R01.1 · Identity or evidence conditions prevented a substantive audit. This is not a clean zero-finding report.
R01.3 · This report belongs to an earlier governance process and does not imply that the current process permits an automatic third round.
Recorded findings by review, round, and severity
Recorded findings by review, round, and severity. Ten review groups on the horizontal axis, one column per audit round inside each group, HIGH recorded findings stacked below MEDIUM. Review 01 Round 1 is marked NOT_AUDITABLE rather than drawn as a zero-height column; Review 01 Round 3 is a historical third round drawn hatched. Tab into the chart, use the arrow keys to move between the 21 reports, Enter to pin a report, Escape to clear. 56 HIGH · 62 MEDIUM · 0 CRITICAL across 21 reports · 118 recorded findings.
- HIGH56
- MEDIUM62
- CRITICAL (no finding recorded as CRITICAL)0
- Round 1
- Round 2
- Historical Round 3
- NOT_AUDITABLE · historical exception
- Recorded findings
- 118
- HIGH
- 56
- MEDIUM
- 62
- CRITICAL
- 0
- Recorded disposition
- 113 fixed · 3 accepted risk · 2 owner decision
No finding was recorded as CRITICAL in this snapshot.
06 · MEASURED TIME
Audit time was measured, not guessed.
The 21 reports record 17,825 seconds of audit time, equal to 297 minutes and 5 seconds. The median report duration was 14 minutes and 18 seconds.
- Total recorded time297m 05s
- Mean across all reports14m 09s
- Median across all reports14m 18s
- Mean across nonzero reports14m 51s
- Shortest nonzero record1m 01s
- Longest record21m 53s
- Round 1
- Round 2
- Historical Round 3
- NOT_AUDITABLE · historical exception
- Median 14m 18s
These timestamps measure the audit-report interval. They do not measure the full engineering cycle, waiting time, remediation time, owner time, or end-to-end delivery time.
Historical exception. Review 01 Round 1 has identical start and completion timestamps and a NOT_AUDITABLE verdict. Its recorded duration is zero and must remain visibly marked as a historical exception.
Recorded audit-report duration by report
Lollipop chart of recorded audit-report duration for each of the 21 reports in sequence, with a median reference at 14 minutes and 18 seconds, a zero-duration historical exception for R01.1, and annotations for the longest (R08.2, 21 minutes and 53 seconds) and shortest nonzero (R01.2, 1 minute and 1 second) records.
- Total recorded time
- 297m 05s (17,825 s)
- Median
- 14m 18s
- Mean
- 14m 09s
- Nonzero mean
- 14m 51s
- Reports
- 21 · 20 nonzero
07 · DISPOSITION
A recorded disposition is not a verified outcome.
Every canonical finding in the stable snapshot has a recorded disposition. Of 118 findings, 113 were recorded as FIXED, 3 as ACCEPTED_RISK, and 2 as OWNER_DECISION_REQUIRED.
- FIXED (recorded)113
- ACCEPTED_RISK (recorded)3
- OWNER_DECISION_REQUIRED (recorded)2
- FIXED (recorded)
- The resolution record states that a fix was made.
- ACCEPTED_RISK (recorded)
- The resolution record accepts the remaining risk.
- OWNER_DECISION_REQUIRED (recorded)
- The resolution record identifies a decision that required owner authority.
FIXED means recorded as fixed in a resolution report. It does not mean that every fix was independently re-audited after the final round.
Follow a flow from severity to recorded disposition, then select a destination to see which review rounds contributed to it.
Complete flow · Stable total 118 findings
Recorded finding disposition
Flow from HIGH (56) and MEDIUM (62) severity to recorded dispositions FIXED (recorded) (113), ACCEPTED_RISK (recorded) (3), OWNER_DECISION_REQUIRED (recorded) (2). Marks are sized in proportion to the count of canonical findings; the complete matrix reconciles to 118.
- FIXED (recorded)
- 113
- ACCEPTED_RISK (recorded)
- 3
- OWNER_DECISION_REQUIRED (recorded)
- 2
- HIGH severity
- 56 of 118
- MEDIUM severity
- 62 of 118
08 · CONTINUATION GATES
Automation must prove its right to continue.
The proposed standing-mandate path evaluates six gates before automatic approval can be available. A blocked gate or an unverifiable gate routes to owner escalation. Unknown evidence never becomes a silent pass.
- All six gates are CLEAR
- Automatic approval may be available within the governing mandate.
- Any gate is BLOCKED
- Stop automatic continuation and escalate to the owner.
- Any gate is UNVERIFIED
- Stop automatic continuation and escalate to the owner.
The interesting state is not only blocked. It is unverified. The system must distinguish missing evidence from evidence that passed.
- CLEAR
- BLOCKED
- UNVERIFIED
In implementation · This simulator explains the intended gate logic. In this package, standing-mandate automatic approval is not represented as a stable main capability.
Six-gate continuation simulator
Explanatory simulator with six categorical gates that can each be CLEAR, BLOCKED, or UNVERIFIED. Any BLOCKED or UNVERIFIED gate routes to owner escalation. The capability is in implementation outside the stable snapshot and no real approval is performed.
This simulator explains the intended gate logic. In this package, standing-mandate automatic approval is not represented as a stable main capability.
Explanatory simulator · no real approval
ResultAutomatic approval may be available within the governing mandate.
- Gate 1, G1
Unresolved CRITICAL or HIGH finding
Does the package retain an unresolved CRITICAL or HIGH finding?
CLEARNo unresolved CRITICAL or HIGH finding remains within the evaluated package.
State · Gate 1- Gate number
- 1 of 6
- Question
- Does the package retain an unresolved CRITICAL or HIGH finding?
- Control type
- Machine checked
- Evidence required
- Validated canonical findings and their current recorded disposition.
- Current scenario state
- CLEAR
- Clear meaning
- No unresolved CRITICAL or HIGH finding remains within the evaluated package.
- Blocked meaning
- At least one unresolved CRITICAL or HIGH finding remains.
- Unverified meaning
- Finding severity or disposition cannot be validated completely.
- Route consequence
- This gate alone does not stop automatic continuation; the result depends on all six gates.
- Implementation status
- IN IMPLEMENTATION OUTSIDE THE STABLE SNAPSHOTThis simulator explains the intended gate logic. In this package, standing-mandate automatic approval is not represented as a stable main capability.
- Gate 2, G2
Package-caused validation regression
Did the package cause a validation regression?
CLEARRequired validation passes and no package-caused regression is detected.
State · Gate 2- Gate number
- 2 of 6
- Question
- Did the package cause a validation regression?
- Control type
- Machine checked
- Evidence required
- Comparable validation evidence bound to the evaluated package and baseline.
- Current scenario state
- CLEAR
- Clear meaning
- Required validation passes and no package-caused regression is detected.
- Blocked meaning
- The package causes a required validation regression.
- Unverified meaning
- Required validation did not run, is incomplete, is stale, or is not bound to the package.
- Route consequence
- This gate alone does not stop automatic continuation; the result depends on all six gates.
- Implementation status
- IN IMPLEMENTATION OUTSIDE THE STABLE SNAPSHOTThis simulator explains the intended gate logic. In this package, standing-mandate automatic approval is not represented as a stable main capability.
- Gate 3, G3
Material scope or architecture change
Did remediation introduce a material scope or architecture change outside the authorized envelope?
CLEARThe change remains within the authorized material scope and architecture boundary.
State · Gate 3- Gate number
- 3 of 6
- Question
- Did remediation introduce a material scope or architecture change outside the authorized envelope?
- Control type
- Mixed check and assertion
- Evidence required
- Validated change boundary plus an explicit assessment of material scope and architecture impact.
- Current scenario state
- CLEAR
- Clear meaning
- The change remains within the authorized material scope and architecture boundary.
- Blocked meaning
- A material change exceeds or alters the authorized boundary.
- Unverified meaning
- The effective change boundary or materiality assessment is incomplete or cannot be established.
- Route consequence
- This gate alone does not stop automatic continuation; the result depends on all six gates.
- Implementation status
- IN IMPLEMENTATION OUTSIDE THE STABLE SNAPSHOTThis simulator explains the intended gate logic. In this package, standing-mandate automatic approval is not represented as a stable main capability.
- Gate 4, G4
Material residual risk
Does material residual risk remain after remediation?
CLEARNo material residual risk requiring owner authority remains.
State · Gate 4- Gate number
- 4 of 6
- Question
- Does material residual risk remain after remediation?
- Control type
- Evidence-bearing assertion
- Evidence required
- Explicit residual-risk assessment linked to findings, remediation, validation, and known limitations.
- Current scenario state
- CLEAR
- Clear meaning
- No material residual risk requiring owner authority remains.
- Blocked meaning
- Material residual risk remains and requires owner judgment or acceptance.
- Unverified meaning
- Residual risk has not been assessed or the evidence is insufficient.
- Route consequence
- This gate alone does not stop automatic continuation; the result depends on all six gates.
- Implementation status
- IN IMPLEMENTATION OUTSIDE THE STABLE SNAPSHOTThis simulator explains the intended gate logic. In this package, standing-mandate automatic approval is not represented as a stable main capability.
- Gate 5, G5
New credential, destructive action, or authority requirement
Does continuation require a new credential, destructive action, or authority not already granted?
CLEARNo new credential, destructive action, or additional authority is required.
State · Gate 5- Gate number
- 5 of 6
- Question
- Does continuation require a new credential, destructive action, or authority not already granted?
- Control type
- Evidence-bearing assertion
- Evidence required
- Explicit action and authority inventory for the evaluated continuation.
- Current scenario state
- CLEAR
- Clear meaning
- No new credential, destructive action, or additional authority is required.
- Blocked meaning
- Continuation requires new authority, credentials, or destructive action outside the mandate.
- Unverified meaning
- The required action or authority boundary cannot be established.
- Route consequence
- This gate alone does not stop automatic continuation; the result depends on all six gates.
- Implementation status
- IN IMPLEMENTATION OUTSIDE THE STABLE SNAPSHOTThis simulator explains the intended gate logic. In this package, standing-mandate automatic approval is not represented as a stable main capability.
- Gate 6, G6
Remediation not proven through execution
Has the relevant remediation been proven through execution?
CLEARRelevant remediation is supported by adequate execution evidence.
State · Gate 6- Gate number
- 6 of 6
- Question
- Has the relevant remediation been proven through execution?
- Control type
- Evidence-bearing assertion
- Evidence required
- Execution evidence linked to the remediation and evaluated package.
- Current scenario state
- CLEAR
- Clear meaning
- Relevant remediation is supported by adequate execution evidence.
- Blocked meaning
- Execution evidence demonstrates failure or incomplete remediation.
- Unverified meaning
- Execution evidence is absent, stale, incomplete, or not bound to the remediation.
- Route consequence
- This gate alone does not stop automatic continuation; the result depends on all six gates.
- Implementation status
- IN IMPLEMENTATION OUTSIDE THE STABLE SNAPSHOTThis simulator explains the intended gate logic. In this package, standing-mandate automatic approval is not represented as a stable main capability.
ResultScenario: All evidence clear
Automatic approval may be available within the governing mandate.
Explanatory all-clear scenario. This is not an actual review and no approval is performed.
- CLEAR
- 6
- BLOCKED
- 0
- UNVERIFIED
- 0
In implementation
Automatic approval may be available within the governing mandate. Explanatory all-clear scenario. This is not an actual review and no approval is performed.
09 · EVIDENCE
Evidence is part of the product.
The system is designed so that authority, implementation, review identity, audit results, remediation, decisions, and promotion can be reconstructed as a connected evidence chain.
Selected artifactDefault
Mission mandate · Authority lane
What was authorized, by whom, and within which boundary?
- Produced by
- Owner
- Consumed by
- Implementation role · Resident orchestrator
- Integrity meaning
- Defines the permitted mission, scope, authority, expiry, and stop boundary.
- Public status
- Explanatory artifact class
- Current capability relationship
- Event-driven audit orchestration · Evidence provenance foundation · Standing-mandate automatic approval · Fully autonomous multi-project engineering · Manual fallback and rollback
A claim without provenance is a story. A claim connected to authority, a pinned snapshot, review, and a durable decision becomes inspectable evidence.
The public graph uses sanitised artifact classes and aliases. It does not expose private commits, paths, account identities, or raw evidence.
Evidence provenance graph
Seven sanitised artifact classes laid out in four lanes (Authority, Engineering, Assurance, Evidence) and connected by ten directed relations: authorizes, scopes, is examined by, requires a disposition in, produces the next review candidate for, provides the authority boundary to, provides assurance evidence to, provides response evidence to, permits or escalates to, and closes. Selecting an artifact highlights its direct producers and consumers; a path control extends the highlight from the mission mandate to the promotion and closure record. The tables below list every artifact and relation.
- Authority lane
- Engineering lane
- Assurance lane
- Evidence lane
- Selected artifact
- Direct producer or consumer
- Produced by
- Owner
- Consumed by
- Implementation role · Resident orchestrator
- Current capability relationship
- Event-driven audit orchestration · Evidence provenance foundation · Standing-mandate automatic approval · Fully autonomous multi-project engineering · Manual fallback and rollback
Explanatory artifact class
Defines the permitted mission, scope, authority, expiry, and stop boundary.
10 · CURRENT STATUS
The foundation is operational. The larger vision is still being built.
The stable snapshot contains a working governed audit foundation: pinned review identity, separate read-only audit, recorded findings and resolutions, a two-round challenge model, evidence artifacts, explicit owner decisions, and event-driven orchestration for an explicitly armed project.
Standing-mandate automatic approval is in implementation outside the stable snapshot. Fully autonomous multi-project engineering remains a future direction, not a current public claim. Manual fallback remains part of the design.
The system does not remove human authority. It removes unnecessary workflow interruption while keeping authority, review, evidence, stop conditions, and rollback explicit.
Current status · Stable evidence snapshot: 31 August 2026
Capability status ladder
9 capabilities grouped into 4 status classes, listed in order: operational in stable evidence, in implementation outside the stable snapshot, future direction, retained fallback. Each row states the public status wording, the as-of date, the public claim, the limitation, and the evidence classes that support it.
Expanded 9 of 9 capabilities
Operational in stable evidence
6 capabilitiesThe stable snapshot contains implementation and evidence supporting the bounded public claim.
- Pinned and attested review snapshotsOperational in stable evidenceas of 31 August 2026 stable snapshot
The stable evidence history includes audit reports bound to identified and attested review material.
Limitation Attestation and integrity evidence do not by themselves prove authenticity against every compromised parent or authority source.
- Pinned review snapshot
- Audit report
- Separate read-only Codex audit roleOperational in stable evidenceas of 31 August 2026 stable snapshot
Canonical reports were produced by a separate read-only review role against pinned material.
Limitation This is a separate system role, not a third-party certification or independent assurance firm.
- Pinned review snapshot
- Audit report
- Two-round governed review loopOperational in stable evidenceas of 31 August 2026 stable snapshot
The stable history contains a governed discovery and verification model for newer reviews.
Limitation Review 01 is a historical exception with an earlier three-round process.
- Audit report
- Resolution record
- Approval provenance
- Findings and resolution traceOperational in stable evidenceas of 31 August 2026 stable snapshot
All 118 canonical findings in the stable snapshot map to one recorded disposition.
Limitation Recorded FIXED does not mean every fix was independently re-audited after the final round.
- Audit report
- Resolution record
- Event-driven orchestrationOperational for an explicitly armed projectas of 31 August 2026 stable snapshot
The stable snapshot records event-driven orchestration for an explicitly armed project while material decisions still escalate.
Limitation This does not establish universal multi-project deployment or human-free operation.
- Mission mandate
- Work package and change scope
- Audit report
- Promotion and closure record
- Evidence provenance foundationOperational in stable evidenceas of 31 August 2026 stable snapshot
The workflow preserves a connected record of scope, review identity, audit, resolution, decision, and closure artifacts.
Limitation The public graph is an artifact-class model and does not claim tamper-proof evidence or cryptographic owner identity.
- Mission mandate
- Work package and change scope
- Pinned review snapshot
- Audit report
- Resolution record
- Approval provenance
- Promotion and closure record
In implementation outside the stable snapshot
1 capabilityWork exists outside the stable public evidence boundary and must not be presented as a stable capability.
- Standing-mandate automatic approvalIn implementation outside the stable snapshotas of 31 August 2026 stable snapshot
A six-gate standing-mandate approval path is being implemented outside the stable public snapshot.
Limitation It must not be presented as stable, production-complete, or available for the snapshot used by the numeric charts.
- Mission mandate
- Audit report
- Resolution record
- Approval provenance
Future direction
1 capabilityAn intended direction without a current operational claim.
- Fully autonomous multi-project engineeringFuture directionas of 31 August 2026 stable snapshot
Broader multi-project autonomy is a future direction, not a current public capability.
Limitation No autonomy score, deployment count, or completion date is approved.
- Mission mandate
- Work package and change scope
- Approval provenance
Retained fallback
1 capabilityA manual or rollback path deliberately remains available.
- Manual fallbackRetainedas of 31 August 2026 stable snapshot
Manual fallback and rollback remain explicit parts of the operating model.
Limitation Fallback availability does not prove that every rollback scenario is risk-free.
- Mission mandate
- Approval provenance
- Promotion and closure record
- Operational in stable evidence
- 6
- In implementation outside the stable snapshot
- 1
- Future direction
- 1
- Retained fallback
- 1
Select a capability to highlight the evidence classes that support its public status.
Methodology
How to read these numbers
The webpage uses one versioned snapshot of the repository's stable branch. Canonical audit reports supply review, round, time, verdict, File Count, and finding severity. Canonical resolution reports supply recorded finding dispositions. Repository file count comes from the stable Git tree. Active development outside the stable snapshot is excluded from numeric aggregates.
Audit counts, finding counts, durations, and file counts are descriptive evidence. They do not prove causality, security, quality, completeness, productivity, or commercial value.
Data extracted 2 September 2026 from the stable snapshot committed 31 August 2026.
Snapshot alias stable-2026-08-31 · dataset 1.0.0 · schema 1.0.0 · validation passed
Data basis
- Reported
- copied from a canonical record
- Derived
- calculated from reported values using a documented formula
- Interpreted
- an analytical statement that is not itself a raw field
- Current status
- an implementation-maturity statement as of the page date
- Historical exception
- a record governed by an earlier process or incomparable condition
Metric formulas
- Review count · Derived
- Distinct public Review aliases represented by canonical audit reports. 10
- Audit-report count · Reported
- Canonical audit-report files in the stable snapshot. 21
- Finding count · Derived
- CRITICAL + HIGH + MEDIUM across canonical reports. 0 + 56 + 62 = 118
- Recorded audit duration · Derived
- Completed At − Started At, summed across 21 reports. 17,825 s = 297m 05s
- Audit File Count · Reported, derived multiple
- Integer recorded as File Count in each report; first measurable and latest. 81 → 329, 329 ÷ 81 = 4.06×
- Repository file count · Derived
- Blob entries in the recursive Git tree of the stable commit. 299
- Paired round comparison · Derived comparison
- Round 1 and Round 2 totals for Review 02 to Review 10. 62 → 52, difference −10
- Recorded disposition · Recorded
- Disposition recorded in the matching resolution report for each canonical finding. 113 FIXED, 3 ACCEPTED_RISK, 2 OWNER_DECISION_REQUIRED
Exclusions and exceptions
- Active-branch exclusion
- Active work outside the stable snapshot is excluded from all numeric aggregates. It appears only as the qualitative status “In implementation outside the stable snapshot”.
- Audit File Count versus repository blob count
- Audit File Count is an attested path count recorded by each report. Repository file count is the number of blobs in the stable Git tree (299). They never share one axis.
- Recorded disposition
- Recorded FIXED means the resolution report states that a fix was made. It does not mean every fix was independently re-audited after the final round.
- Historical exception · R01.1
- Identity or evidence conditions prevented a substantive audit. This is not a clean zero-finding report.
- Historical exception · R01.3
- This report belongs to an earlier governance process and does not imply that the current process permits an automatic third round.