Original ledgers, exit conditions and derived views

The following pages derive from eleven original CSV files; they do not establish a second status database. Each task preserves its original identifier, order, all fields, exit conditions, implementation status, software/physical status and original evidence locators; the source SHA-256 is available for comparison. If an original CSV has no separate exit field, this is explicit; no passed condition may be assembled from another ledger.

R01–R48 in soc-ip-layout preserve original directory and shared-IP refactor states. R43–R48 record software execution, segmented plan coverage, SDK, resources and the candidate for exact P; generating this page does not change physical not_executed values. Find the latest results through the software evidence entry.

Interpret statuses correctly

  • implemented means implementation exists; it does not guarantee complete software qualification for the current checkout.

  • development_passed retains its development-validation meaning; do not expand it into formal clean-source archiving.

  • Consult the exact results index for qualification_record_authority.

  • implemented_tooling only means tooling is implemented; unexecuted physical work remains not_executed.

  • not_implemented, not_executed, failures and conditional extensions retain their original values.

  • Different workstreams cover overlapping mechanisms; do not add their counts or calculate project-wide completion percentages.

platform-delivery-completion remains the same follow-up task authority after the developer-experience iteration. It preserves N01–N14 and adds the complete A01–J04 and X01–X05 work breakdown. It does not rewrite the original 75-task exit conditions or P/E software identities. Each full exit remains intact; migrating one peripheral cannot close a whole-family task. N11 and the H-group physical tasks require real equipment. N13 and the J-group software sealing require the current clean source, complete plan and offline reproduction; old candidates or development tests do not replace them.

The 71 iteration entries after v0.2.1 reuse this ledger: 36 items map to original tasks and 35 new exits use IT- IDs. The planning map maintains no second status; new rows begin as planned/not_executed, while the original 175 rows retain IDs, order and evidence. Existing passes still apply only to their original tested sources and cannot close new iteration scope.

This iteration’s C cold-lifecycle and engineering delivery observations continue in current_iteration_20261028 within the same results index. An implemented family row records C responsibility for its maintained paths; development models, ARM checks and final integrated-source qualification remain separate. The first clean increment’s SDK/bilingual documentation and a later commit’s ordinary gate do not automatically cover new worktrees; actual physical execution for group H remains not_executed.

platform-refinement retains the earlier 60-item refinement record; io-evolution is the current 42-item increment ledger. Both reuse IO- IDs, but their sources, tasks and exit conditions differ. Always name the CSV or derived page; do not merge statuses by ID. The increment ledger retains its original not_qualified values. Generating a view does not execute tests or promote software or physical qualification.

The old 48-item OS checklist has been expanded. Current CSV IDs are OS01–OS55; OS49–OS55 cover physical tooling/actual acceptance, with all original statuses retained. The 48 build-system tasks form a separate ledger. Historical RF ledgers remain under docs/archive/implementation/, reachable through the history entry, and cannot establish current support qualification.

Maintain derived pages

python -m tools.documentation.status
python -m tools.documentation.status --check

The first command only regenerates views from the same original CSV. The second checks missing/stale output, returns nonzero on failure and writes nothing. Regenerate after changing original ledgers; commit/CI checks the same derivation relationship. Successful generation/checking only proves documentation matches original fields; it executes no firmware and acquires no hardware observations. Actual test evidence is in the original results indexes.