Governance

Governance Framework

The NEPA governance framework defines the structural controls that ensure inspection outputs are attributable, reproducible, and defensible. This documentation is intended for regulatory reviewers, compliance stakeholders, and enterprise procurement teams conducting technical due diligence.

01 — Inspection Run Version Control

Inspection Run Version Control

Every inspection run is assigned a unique, immutable run identifier that binds together all components of the system state at the time of execution. This binding is cryptographic and cannot be modified after the run is initiated.

01Run ID Generation — a unique run identifier is generated at initialisation, incorporating timestamp, engine version, and configuration hash
02Engine Version Binding — the SHA-256 fingerprint of the deployed binary is recorded in the run manifest before the first frame is processed
03Configuration Contract Binding — the versioned configuration contract is hashed and locked; no parameter modification is possible after binding
04Operator Authentication Record — the authenticated operator identity is bound to the run manifest via signed token
05Hardware Attestation — the inspection node's hardware identity and sensor calibration certificates are recorded in the run manifest

# Run Manifest — Sealed

run_id: "nepa-2026-03-17-HK"

engine_version: "2.4.1"

engine_sha: "a7f3c8d4..."

config_contract: "v2.4.1-stable"

config_hash: "e2b9f1c3..."

operator_token: "SIGNED"

manifest_seal: IMMUTABLE

02 — Configuration Immutability

Configuration Immutability

The analytical configuration governing each inspection run is sealed at run-start and cannot be modified during execution. This property is enforced at the architecture level, not by access controls.

■

Pre-Run Parameter Locking

All analytical parameters — detection thresholds, lane weights, fusion coefficients, and confidence bounds — are hashed and sealed before the first frame enters the pipeline.

◆

Immutability Enforcement

Parameter modification after run-start is architecturally prevented. Any attempt to alter parameters mid-run is logged as a critical governance violation and terminates the run.

◇

Configuration Versioning

Every configuration contract is stored under a versioned identifier. The full history of configuration changes is maintained with structured diffs and approval records.

03 — Audit Logging Structure

Audit Logging Structure

The NEPA audit log is an append-only, hash-linked record of all system events from run initialisation to evidence archival. It is designed to support independent forensic analysis without requiring access to internal tooling.

01Append-Only Write Model — log entries cannot be modified or deleted; the log grows monotonically throughout the run
02Hash-Linked Block Structure — each log entry includes the hash of its predecessor, creating a tamper-evident chain
03Structured Event Schema — every event type has a defined schema; free-text entries are prohibited
04Timestamp Authority — all log entries are timestamped against a hardware time source; drift is detected and logged
05Chain Seal Verification — the complete audit chain is sealed at run-end; post-run verification is available to authorised auditors

The audit log is designed to be self-describing. An authorised third-party auditor with access to the log, the run manifest, and the replay package has sufficient information to independently validate any finding without further access to internal systems.

04 — Evidence Retention Model

Evidence Retention Model

All inspection evidence is retained in a structured, queryable archive with defined retention periods, access controls, and integrity verification schedules.

Evidence Type	Retention Period	Integrity Check	Auditor Access
Raw Sensor FramesOriginal camera, LiDAR, thermal data	7 years	Weekly SHA-256 verification	Available
Processed Spike RepresentationsNeuromorphic encoded data	7 years	Weekly SHA-256 verification	Available
Inspection FindingsDerived defect records with confidence scores	Indefinite	Daily integrity scan	Available
Audit Chain LogsComplete event logs with hash linkage	Indefinite	Continuous chain validation	Available
Configuration ContractsVersioned analytical parameter records	Indefinite	On-access hash verification	Available
Replay Attestation PackagesThird-party auditor evidence packages	10 years	On-generation signing	Available

05 — Change Management Discipline

Change Management Discipline

All changes to the NEPA platform — including engine updates, configuration modifications, and infrastructure changes — follow a structured change management process designed to maintain the integrity of the audit and evidence systems.

01Change Request Documentation — every proposed change is documented with rationale, scope, and risk assessment before review
02Impact Assessment — changes are assessed for their effect on determinism guarantees, audit chain integrity, and evidence compatibility
03Regression Validation — all changes must pass the full automated regression suite before approval, including determinism verification and replay validation
04Signed Release Records — approved changes are released under signed, immutable release records with full diff documentation
05Change Audit Trail — every approved change is recorded in the governance audit trail, accessible to authorised reviewers

Control	Status
Determinism Policy Documentation	Active
Change Control Process	Active
Parameter Locking Enforcement	Active
Fault Injection Test Suite	Active
Readiness Matrix Review	In Progress
Third-Party Audit Program	Available on Request

Governance Documentation Available

Full governance documentation packages are available for regulatory reviewers and enterprise procurement teams upon formal request.

Request Documentation Technical Architecture