Software verification, source identity and evidence¶
This page navigates existing execution records; it does not establish platform-software qualification for this documentation HEAD. Compare source, assembly, dependencies, tools, actual execution and the same ELF/BIN/map bytes together, rather than reading passed alone. The qualification contract maintains qualification rules.
Interpret three identities separately¶
The following fields apply to successfully packaged formal sites and offline packages. For build previews, first inspect source, status and original command receipts in documentation-build.json. A preview has no formal documentation-manifest.json yet and does not establish release completion.
Identity |
Location |
Meaning |
|---|---|---|
Current code source |
|
The checkout, tree, dirty status and code paths described by this site |
Current documentation source |
|
Exact commit/tree for this formal documentation package; not a replacement for preview-build records |
Referenced qualification source |
|
Earlier exact-code execution; no qualification automatically inherited by current code/documentation HEAD |
After successful packaging, manifests for the public site and offline package derive from actual build inputs. Documentation commits may change Git HEAD; this page does not manually insert a rapidly drifting HEAD constant. An unpackaged working tree can run git rev-parse HEAD to check its checkout, but that command output alone is not a qualification receipt.
Three existing independent results indexes¶
Scope |
Exact code source |
Original authority and execution explanation |
|---|---|---|
Build system and its actual software scopes |
|
|
SoC extension software slices |
|
|
Earlier SoC refinement baseline |
|
The three indexes retain their original schemas, scopes, failed attempts, receipts, archives and member identities. Do not add test executions, ARM images or task counts, or calculate a project-wide completion rate. Later documentation commits only record these baselines. Current documentation checking, rendering, offline recovery and deployment validation each have independent records.
The build-system records did not execute one complete 72-stage software master plan, OCI recipe reconstruction, CP311 offline installation, Windows/macOS integration or MCU HIL. Interpret independently executed scopes according to their original indexes; do not expand conclusions from aggregate status. Eight current unsigned software candidates combine empty/UART and baremetal/FreeRTOS for H743 HSI64/Cache off and U575 MSIS4/TZEN=0.
Acquire and verify earlier evidence¶
Open the corresponding results index and confirm the canonical code commit, configuration and recorded scope.
Locate the archive through the index and verify SHA-256 and bytes; retain the original identities of failed attempts.
Locate members using original fields such as
archive_relative_pathandarchive_member_relative_path, then verify each member’s hash and bytes. Field names vary by original schema; interpret them according to that index.Inspect actual execution records, raw logs and the same artifacts. Software models, linking, independent consumption and two network-disabled rebuilds prove their own scopes; success in one does not replace another.
Assess physical records separately according to HIL status.
Original /workspace/... and /dev/shm/... paths locate the execution host; they are not public downloads elsewhere. The build-system index’s evidence_navigation specifies candidate archives, candidate documents, ELF/BIN/map and complete member-inventory locations. Archives are currently retained locally as recorded; do not invent download URLs for unpublished remote evidence. Documentation packages include original JSON for checking; they do not copy large raw archives or re-sign historical bytes.
FIG-11 expresses qualification relationships without generating receipts. See the diagram atlas for standards and source authorities, and the ledger views for original per-task exit conditions.