Technical Specification

Immutable Audit Boundary

Formal specification of audit artifact format, signing scheme, and verification procedure.

Overview

The V2 Engine produces a cryptographically signed audit artifact for each execution. These artifacts create an immutable record of what was evaluated, when, and with what result.

This specification defines the artifact structure, serialization format, signing algorithm, and verification procedure.

Version: 1.0
Status: Current
Last Updated: February 2026

Artifact Structure

Each audit artifact is a JSON document containing:

{
  "version": "1.0",
  "timestamp": "2026-02-04T19:23:15.000Z",
  "engine_version": "2.1.0",
  "ruleset_version": "2024-Q4",
  "ruleset_hash": "sha256:e5f6g7h8...",
  "input_hash": "sha256:a1b2c3d4...",
  "output_hash": "sha256:i9j0k1l2...",
  "environment": {
    "deployment_id": "prod-01",
    "runtime": "node-20.11.0",
    "platform": "linux-x64"
  },
  "execution": {
    "duration_ms": 245,
    "rules_evaluated": 1247,
    "rules_triggered": 3
  },
  "signature": {
    "algorithm": "RSA-SHA256",
    "key_id": "deploy-key-001",
    "value": "base64-encoded-signature"
  }
}

Field Definitions

version

Artifact format version. Current: "1.0"

timestamp

ISO 8601 UTC timestamp of execution start

engine_version

Semantic version of the V2 Engine binary

ruleset_version

Version identifier of the rule set

ruleset_hash

SHA-256 hash of the rule set used for execution

input_hash

SHA-256 hash of the canonical input data

output_hash

SHA-256 hash of the execution output

environment

Deployment environment metadata

execution

Execution statistics (duration, rules evaluated, rules triggered)

signature

Cryptographic signature of the artifact

Canonical Serialization

To ensure reproducible signatures, the artifact must be serialized in a deterministic format before signing.

Rules

  • Field order: Fields must appear in alphabetical order
  • Whitespace: No unnecessary whitespace or line breaks
  • Unicode: UTF-8 encoding without BOM
  • Numbers: No leading zeros or trailing decimals
  • Signature exclusion: The signature field is excluded from the canonical representation

Example

{"engine_version":"2.1.0","environment":{"deployment_id":"prod-01","platform":"linux-x64","runtime":"node-20.11.0"},"execution":{"duration_ms":245,"rules_evaluated":1247,"rules_triggered":3},"input_hash":"sha256:a1b2c3d4...","output_hash":"sha256:i9j0k1l2...","ruleset_hash":"sha256:e5f6g7h8...","ruleset_version":"2024-Q4","timestamp":"2026-02-04T19:23:15.000Z","version":"1.0"}

Signing Algorithm

Artifacts are signed using RSA-4096 with SHA-256 (RSASSA-PKCS1-v1_5).

Process

  1. 1. Serialize: Generate canonical JSON representation (excluding signature field)
  2. 2. Hash: Compute SHA-256 hash of the canonical representation
  3. 3. Sign: Sign the hash using RSA-4096 private key
  4. 4. Encode: Base64-encode the signature
  5. 5. Embed: Add signature field to the artifact

Key Management

Each deployment uses a unique key pair for signing audit artifacts. The private key must be:

  • Generated within the deployment environment (never transmitted)
  • Stored securely (HSM or encrypted key store)
  • Access-controlled (least privilege)
  • Rotated periodically (recommended: annually)

The public key must be:

  • Published in a trusted location
  • Associated with a key identifier (key_id)
  • Protected from unauthorized modification

Verification Procedure

To verify an audit artifact:

Steps

  1. 1. Parse: Parse the artifact as JSON
  2. 2. Extract signature: Extract the signature.value and signature.key_id fields
  3. 3. Retrieve public key: Fetch the public key corresponding to key_id
  4. 4. Reconstruct canonical form: Serialize the artifact without the signature field
  5. 5. Verify signature: Verify the signature using the public key and RSA-SHA256
  6. 6. Verify hashes: Optionally verify input_hash and output_hash match provided data

Example (Pseudocode)

// Load artifact
artifact = JSON.parse(artifact_json)

// Extract signature
signature = base64_decode(artifact.signature.value)
key_id = artifact.signature.key_id

// Retrieve public key
public_key = get_public_key(key_id)

// Reconstruct canonical form
canonical = canonical_serialize(artifact, exclude: ["signature"])

// Verify signature
is_valid = rsa_verify(
  public_key: public_key,
  message: canonical,
  signature: signature,
  algorithm: "RSA-SHA256"
)

if (!is_valid) {
  throw "Signature verification failed"
}

// Optionally verify hashes
if (input_data) {
  expected_hash = sha256(canonical_serialize(input_data))
  if (artifact.input_hash != expected_hash) {
    throw "Input hash mismatch"
  }
}

if (output_data) {
  expected_hash = sha256(canonical_serialize(output_data))
  if (artifact.output_hash != expected_hash) {
    throw "Output hash mismatch"
  }
}

Failure Modes

Signature Verification Failure

Cause: Artifact has been tampered with or corrupted after signing.

Action:

  • Reject the artifact
  • Investigate the source of tampering
  • Check audit log storage integrity
  • Report to security team

Input Hash Mismatch

Cause: The provided input data does not match the execution record.

Action:

  • Verify input data source
  • Check for data corruption
  • Ensure canonical serialization is correct

Output Hash Mismatch

Cause: Output has been modified post-execution.

Action:

  • Reject the output
  • Investigate modification source
  • Re-execute if necessary

Missing Key ID

Cause: Signing key is not available for verification.

Action:

  • Check key registry
  • Verify key_id is correct
  • Restore key from backup if rotated

Sample Artifact (Redacted)

Below is a complete audit artifact with redacted sensitive values:

{
  "version": "1.0",
  "timestamp": "2026-02-04T14:23:45.123Z",
  "engine_version": "2.1.0",
  "ruleset_version": "2024-Q4",
  "ruleset_hash": "sha256:7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069",
  "input_hash": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  "output_hash": "sha256:2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae",
  "environment": {
    "deployment_id": "prod-us-east-1",
    "runtime": "node-20.11.0",
    "platform": "linux-x64"
  },
  "execution": {
    "duration_ms": 312,
    "rules_evaluated": 1543,
    "rules_triggered": 7
  },
  "signature": {
    "algorithm": "RSA-SHA256",
    "key_id": "deploy-key-2026-01",
    "value": "rBMYcVQ2J...{redacted}...xKp2Nw=="
  }
}

Implementation Notes

Storage Recommendations

  • Store artifacts in append-only storage (prevent modification)
  • Use immutable storage backends (e.g., WORM, object storage with versioning)
  • Implement retention policies aligned with regulatory requirements
  • Backup artifacts to separate, tamper-resistant location

Performance Considerations

  • Signing adds ~5-10ms overhead per execution
  • Verification is faster than signing (~2-5ms)
  • Consider batch verification for large audit reviews

Compliance Considerations

This artifact structure supports:

  • HIPAA audit trail requirements (45 CFR § 164.312(b))
  • FDA 21 CFR Part 11 (electronic records and signatures)
  • SOC 2 Type II (audit logging and integrity controls)