What actually arrives, field by field.

Software Bill of Materials

Emitted in CycloneDX and SPDX. Neither format is ours, both are published standards, and the point of showing it is that the component entries carry the traceability an assessor needs back to findings.

SPECIMEN CycloneDX shape. Values are illustrative.

{
  "bomFormat": "CycloneDX",
  "specVersion": "<spec version>",
  "serialNumber": "urn:uuid:<uuid>",
  "version": 1,
  "metadata": {
    "timestamp": "<RFC 3339 timestamp>",
    "component": { "type": "container", "name": "<image name>", "version": "<tag>" }
  },
  "components": [
    {
      "type": "library",
      "name": "<component name>",
      "version": "<version>",
      "purl": "pkg:<ecosystem>/<namespace>/<name>@<version>",
      "licenses": [ { "license": { "id": "<SPDX license identifier>" } } ],
      "hashes": [ { "alg": "SHA-256", "content": "<hash>" } ],
      "supplier": { "name": "<supplier>" }
    }
  ],
  "dependencies": [
    { "ref": "<component purl>", "dependsOn": ["<component purl>"] }
  ]
}

Federal context: OMB M-26-05, issued 23 January 2026, rescinded the government-wide secure software attestation common form previously set by M-22-18 and M-23-16, and directs agencies to set their own risk-based assurance requirements. Agencies may still require a self-attestation and an SBOM. Producing both continuously, rather than on demand, is the point of the product.

Model card

A model card that lists no limitations is a marketing document. The fields below are the ones we require to be populated before a model card is considered complete, and the limitations section is mandatory.

SPECIMEN Required fields. Values are illustrative.

Model              <name and version>
Weights digest     sha256:<hash>
Licence            <licence identifier and any use restrictions>
Hosting            self-hosted in boundary | authorized managed service

Intended use       <the task the model is authorized to perform in this system>
Out of scope use   <uses explicitly not authorized>
Users              <who interacts with the output, and under what supervision>

Evaluation
  Suite            <evaluation suite identifier and version>
  Conditions       <environment the evaluation was run in>
  Results          <measured results, with the date measured>

Limitations        // mandatory, never empty
  <known failure modes>
  <conditions under which output degrades>
  <populations, inputs, or domains where performance is not characterized>

Human oversight    <the review step that stands between output and action>
Review             Owner <role>   Last reviewed <date>   Next review <date>

Control mapping

This is the join between engineering output and the assessor's baseline. One control is usually satisfied by several pieces of evidence, and one piece of evidence usually serves several controls, which is why Vigil models it as a graph rather than a list.

SPECIMEN Structure is accurate. Control identifiers shown are real NIST SP 800-53 Rev. 5 identifiers; the evidence references and statuses are illustrative.

{
  "baseline": "NIST SP 800-53 Rev. 5",
  "overlay": "<agency or programme overlay, if any>",
  "mappings": [
    {
      "control": "CM-8",                         // System Component Inventory
      "implementationStatus": "implemented | partially implemented | planned | not applicable",
      "evidence": [
        { "ref": "sbom/cyclonedx.json", "sha256": "<hash>", "generatedAt": "<timestamp>", "freshness": "<age>" }
      ],
      "narrative": "<how the evidence satisfies the control, in the assessor's language>",
      "inheritedFrom": "<platform or provider, where the control is inherited>"
    },
    {
      "control": "RA-5",                              // Vulnerability Monitoring and Scanning
      "implementationStatus": "implemented",
      "evidence": [
        { "ref": "findings/normalized.json", "sha256": "<hash>", "generatedAt": "<timestamp>", "freshness": "<age>" },
        { "ref": "poam/poam.csv",            "sha256": "<hash>", "generatedAt": "<timestamp>", "freshness": "<age>" }
      ],
      "narrative": "<...>"
    }
  ],
  "coverage": { "controlsInBaseline": "<n>", "controlsWithEvidence": "<n>", "stale": "<n>" }
}

Export to OSCAL is available where the receiving programme uses it. We do not claim OSCAL validation against a specific profile without naming the profile.

Audit record entry

Every access, inference, and data flow across the portfolio writes an entry in this shape. Entries are hash chained, so removing or altering one breaks verification of every entry after it.

SPECIMEN Structure is accurate. Values are illustrative.

{
  "seq": "<monotonic sequence number>",
  "timestamp": "<RFC 3339 timestamp>",
  "tenant": "<tenant identifier>",
  "actor": { "type": "user | service | agent", "id": "<identifier>", "authn": "<method>" },
  "action": "<verb, for example read, classify, infer, export, publish>",
  "resource": { "kind": "<type>", "id": "<identifier>", "classification": "<label>" },
  "decision": { "outcome": "allow | deny | transform", "policy": "<policy identifier and version>" },
  "inference": {                                // present only when a model was called
    "model": "<model name and version>",
    "hostingMode": "self-hosted-in-boundary | authorized-managed-service",
    "groundingRefs": ["<document identifiers the answer was grounded in>"]
  },
  "prevHash": "sha256:<hash of the previous entry>",
  "entryHash": "sha256:<hash of this entry>"
}

Where an audit write fails, the operation it describes fails with it. An action that cannot be recorded does not proceed.