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

code_source in the site’s documentation-manifest.json

The checkout, tree, dirty status and code paths described by this site

Current documentation source

documentation_source in the same manifest

Exact commit/tree for this formal documentation package; not a replacement for preview-build records

Referenced qualification source

qualified_code and its results index in the same manifest

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

cc6a065c002041234a212a964be863a69198f9b4

Results index, execution records

SoC extension software slices

98270512ea2ff7eefe8ff79720018e582be3a949

Results index, execution records

Earlier SoC refinement baseline

3728b334b02eb2eb70bcf5d4caafbb9746837dd3

Results index, execution records

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

  1. Open the corresponding results index and confirm the canonical code commit, configuration and recorded scope.

  2. Locate the archive through the index and verify SHA-256 and bytes; retain the original identities of failed attempts.

  3. Locate members using original fields such as archive_relative_path and archive_member_relative_path, then verify each member’s hash and bytes. Field names vary by original schema; interpret them according to that index.

  4. 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.

  5. 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.

Software and physical evidence separately bind exact source and execution scope

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.