# CER Audit Workflows

URL: https://docs.nexart.io/docs/cer-audit-workflows

Audit workflows for Certified Execution Records, covering evidence pack exports, reviewer checks, retention considerations, and how auditors verify records.

Certified Execution Records can be used as durable execution evidence in audit, compliance, and review workflows. This page defines how CER evidence should be packaged, exported, and reviewed without changing the underlying protocol artifacts.

Audit workflows operate at the evidence-packaging and record-management layer, not the cryptographic protocol layer. CER bundles, certificate hashes, signed receipts, and verification semantics remain unchanged.

## Evidence Pack

An evidence pack is a structured export of one or more CER records and their supporting verification materials. The purpose of an evidence pack is to allow independent review, offline verification, and durable audit preservation.

An evidence pack may include:

- CER bundle(s)
- Signed receipt(s)
- Verification result(s)
- Node metadata snapshot
- Export manifest
- Human-readable evidence summary

## Export Manifest

Every evidence pack should include a machine-readable manifest describing what was exported, when, and by whom. The manifest enables automated processing and audit trail tracking.

Recommended manifest structure:

| Field | Description |
| --- | --- |
| exportedAt | ISO 8601 timestamp of the export |
| exportedBy | Identity or organization that triggered the export |
| recordCount | Number of CER records included |
| exportScope | Scope filter used (project, application, time range, etc.) |
| verificationTool | Tool and version used for verification at export time |
| records[] | Array of record entries |

Each record entry includes:

| Field | Description |
| --- | --- |
| executionId | Unique execution identifier |
| certificateHash | Deterministic hash of the CER bundle |
| bundleType | Type of bundle included (e.g. full) |

Example: Export Manifest

```
{
  "exportedAt": "2025-06-15T10:30:00Z",
  "exportedBy": "org:acme-corp",
  "recordCount": 3,
  "exportScope": "project:compliance-review-q2",
  "verificationTool": "nexart-verify@1.2.0",
  "records": [
    {
      "executionId": "exec_abc123",
      "certificateHash": "sha256:9f86d08...",
      "bundleType": "full"
    },
    {
      "executionId": "exec_def456",
      "certificateHash": "sha256:a3c1e7b...",
      "bundleType": "full"
    },
    {
      "executionId": "exec_ghi789",
      "certificateHash": "sha256:e4d909c...",
      "bundleType": "full"
    }
  ]
}
```

## Verification Snapshot

Evidence packs should include a verification result captured at the time of export. This allows reviewers to see the verification outcome that was observed when the package was generated.

Suggested fields:

| Field | Description |
| --- | --- |
| verifiedAt | Timestamp of the verification |
| status | Overall result (VERIFIED or FAILED) |
| checks | Individual check results (bundleIntegrity, nodeSignature, receiptConsistency) |
| reasonCodes | Codes explaining any failures |
| verifier | Tool and version used |

Example: Verification Snapshot

```
{
  "verifiedAt": "2025-06-15T10:30:12Z",
  "status": "VERIFIED",
  "checks": {
    "bundleIntegrity": "PASS",
    "nodeSignature": "PASS",
    "receiptConsistency": "PASS"
  },
  "reasonCodes": [],
  "verifier": "nexart-verify@1.2.0"
}
```

Later reviewers may independently re-run verification using the exported artifacts and the verification rules defined in the CER Protocol.

## Node Metadata Snapshot

When node attestation is present, evidence packs should include a snapshot of the node metadata used for verification at export time. This improves reproducibility of later receipt verification.

Suggested contents:

- `nodeId`: identifier of the attestation node
- `activeKid`: key identifier active at export time
- `keys[]`: public key material used for receipt verification
- `protocolVersion`: protocol version if available

Example: Node Metadata Snapshot

```
{
  "nodeId": "nexart-node-01",
  "activeKid": "key-2025-06",
  "keys": [
    {
      "kid": "key-2025-06",
      "algorithm": "Ed25519",
      "publicKey": "MCowBQYDK2VwAyEA..."
    }
  ],
  "protocolVersion": "1.0"
}
```

This is an audit packaging recommendation. It does not change the attestation node protocol itself.

## Export Scope and Filters

Evidence packs may be generated for a variety of scopes. Audits rarely export all records. Scoping ensures relevance and efficiency.

Supported export scopes include:

- A single execution
- A project
- An application
- A time range
- A specific certificate hash
- An execution surface

Multiple scopes may be combined to produce focused evidence packs suitable for specific review workflows.

## Offline Verification

Evidence packs should support independent verification without requiring live access to NexArt infrastructure.

An auditor should be able to verify a record using:

- The CER bundle
- The signed receipt
- The node public key material
- The verification rules defined in the CER Protocol

Online services may improve convenience (e.g. key discovery, status lookups), but they are not required for evidence validation.

## Review-Oriented Outputs

Evidence packs may include both machine-readable and human-readable materials to support different review workflows.

### Machine-Readable

- `cer.json`: CER bundle
- `receipt.json`: signed attestation receipt
- `verification-report.json`: verification result
- `manifest.json`: export manifest

### Human-Readable

- `evidence-summary.html`: formatted evidence overview
- Reviewer notes
- Exported summary report

## Relationship to CER Record Management

Audit workflows rely on the lifecycle, archival, retention, and record-action semantics defined in CER Record Management.

- Archived records may still be exported into evidence packs
- Hidden records may remain accessible to authorized audit workflows
- Deleted records may still be verifiable if previously exported

The audit workflow model builds on the governance and lifecycle controls defined at the record-management layer. It does not replace them.