Evidence Pack Specification v1

Specification ID	Version	Status	Classification
SPEC-EPK-01	v1.0.0 (Draft)	PROPOSED FOR SYSTEM USE	PUBLIC SPECIFICATION

---

1. Document Status & Scope

This document defines the file structure, metadata schemas, and cryptographic constraints of the OmeraCode Evidence Pack (EPK) format v1. This format is designed to bundle engineering requirements, deterministic solver logs, layout clearance reports, review history, and manufacturing release files into a single, verifiable archive.

2. Terminology

• EPK: Evidence Pack (represented as a directory tree or compressed .epk tarball).
• Deterministic Solver: A mathematical solver executing closed physical equations (e.g. IPC-2152 temperature models) with zero statistical heuristic variance.
• Release Gate: A Boolean validation check that must evaluate to TRUE before compiling signature payloads.
• Integrity Hash: A SHA-256 digest calculated over a specific directory component.

3. Package Structure

An EPK package must conform to the following directory layout:

[release_package].epk/
├── metadata.json           # Global package metadata & hash manifest
├── requirements/
│   ├── specs.json          # Machine-readable requirement parameters
│   └── trace_matrix.json   # Mapping of requirements to physical nets
├── verification/
│   ├── solvers/
│   │   └── [solver_id].json # Mathematical solver inputs, outputs, and formulas
│   ├── drc/
│   │   └── drc_report.json  # Electrical spacing and DFM violations reports
│   └── reviews.json        # Design review sign-off notes & overrides history
├── release/
│   ├── gerber/             # Production-ready Gerber layouts and drills
│   ├── schematic.pdf       # Released schematics
│   └── bom.csv             # Bill of Materials file
└── signatures/
    └── system_keys.sig     # Cryptographic signature payload

4. Artifact Requirements

4.1 Requirements Manifest (specs.json)

The requirements file must explicitly structure electrical, thermal, and spatial parameters. For example:

{
  "requirements": [
    {
      "id": "REQ-089",
      "description": "Continuous current load capability",
      "parameter": "net.VCC_SYS.max_current",
      "target_value": "10.0",
      "unit": "A",
      "source_document": "SPECS-POWER-BOARD-V2.pdf"
    }
  ]
}

4.2 Solver Log Format ([solver_id].json)

Calculations must document formulas, inputs, outputs, and safety margin thresholds:

{
  "solver_instance": "SOLVER-2152-RUN",
  "physical_law": "IPC-2152 Thermal Current Capacity",
  "inputs": {
    "target_current": 10.0,
    "net_name": "VCC_SYS",
    "ambient_temperature": 25.0,
    "max_temperature_rise": 20.0
  },
  "outputs": {
    "min_copper_cross_section": 0.157,
    "target_trace_width": 4.25,
    "evaluated_trace_width": 4.50,
    "calculated_temperature_rise": 14.8
  },
  "validation": {
    "status": "PASS",
    "margin": 5.2
  }
}

5. Release Readiness Gates

The OmeraCode compiler enforces six release readiness gates. These gates check parameter state alignment:

1. Requirements Traced Gate: All records in specs.json must map to at least one entry in trace_matrix.json.
2. Calculations Verified Gate: All calculated variables must fall within safe tolerance bands calculated by deterministic solvers. Mismatches greater than 1% halt compilation.
3. DRC Clean Gate: Design Rule Check reports must have zero unresolved errors. Warnings must compile with an associated review record override.
4. Review Findings Resolved Gate: All review entries in reviews.json flagged as HIGH severity must be in RESOLVED or ACCEPTED status.
5. Manufacturing Package Generated Gate: Schematic PDF, Gerber files, and BOM CSV must be compiled and present in the release/ directory.
6. Package Signed Gate: Cryptographic digests must match the manifest metadata before final signature.

6. Integrity Requirements

To prevent post-release state drift (such as swapping a component value in a schematic without recalculating trace clearances), the EPK applies a simple checksum cascade:

1. A SHA-256 hash is computed for each subdirectory (requirements/, verification/, release/).
2. These digests are compiled into a manifest array inside metadata.json.
3. The manifest is encrypted using the engineer’s private pgp key, producing system_keys.sig.
4. Any post-release alteration to layouts, BOM, or review logs immediately invalidates the signature payload.

7. Limitations & Future Revisions

• v1 Scope Boundary: The v1 specification is strictly limited to rigid, single-board PCBs. Flexible stackups and multi-board chassis constraints will be defined in future v2 specification cycles.
• No Real-Time Simulation: Static calculation logs are supported; transient SPICE simulations are outside the scope of current EPK metadata files.