Governed Execution

Cryptographically verifiable evidence of governed AI and multi-agent workflows: execution path, governance signals, resource safety and concrete causal lineage.

@nexart/governed-execution0.4.2NexArt Node0.30.1

Definition. Governed Execution records the execution path, policy and governance decisions, resource-safety results and causal lineage of an AI or software workflow as a Certified Execution Record with bundle type cer.governed.execution.v1. A Governed CER is execution evidence, not an event log: its protected content is bound by a deterministic certificateHash that any holder can recompute.

NexArt is an AI Evidence Layer and verifiable execution infrastructure. Observability helps operators understand behaviour; logs record events but require trust in whoever produced them; governance defines policies and decision controls. NexArt creates independently verifiable evidence of what was recorded.

Identifiers

bundleType: cer.governed.execution.v1
version: 0.1 (the protected container version, independent of the npm package version)
profile.id: cage-governance-v1, profile.version: "1"

Topology versus lineage

Static topology describes what could execute. It may contain cycles and self-edges, for example a bounded refinement loop. Concrete lineage describes what actually executed and must be acyclic. See Topology and Concrete Lineage.

Five separate operations

Producer
   |  sealGovernedExecution()        no Node, no API key
   v
Local seal  ---> certificateHash
   |
   |  POST /v1/cer/verify            stateless, not persisted, not signed
   v
Stateless verification (optional)
   |
   |  POST /api/attest               API key, persisted, signed receipt
   v
Authenticated attestation (optional)
   |
   |  keys from /.well-known/nexart-node.json
   v
Independent verification

Public publication is a separate, explicit outcome.

Producer to independent verification. Sealing, stateless verification, attestation and independent verification are distinct steps. None of them publishes the record. Attested governed records default to hidden; there is no governed public-reseal workflow.

Local sealing. The SDK creates the canonical CER and its certificateHash. No Node, API key or receipt is involved.
Stateless verification. POST /v1/cer/verify validates a submitted CER and returns structured results. It does not persist, publish or sign.
Authenticated attestation. POST /api/attest requires an API key, validates the bundle, persists an attestation under the Node's retention and visibility rules and returns a signed receipt.
Independent verification. A holder of the complete CER verifies integrity, the receipt signature and the verification-envelope signature using keys from GET /.well-known/nexart-node.json, without trusting a Node ok field.
Public publication. A separate outcome. Governed records default to hidden; see persistence versus publication for what Node 0.30.1 supports.

What it proves and does not prove

What this proves

Integrity of the protected CER bundle.
Causal consistency of recorded execution steps.
Validity of selected concrete edges against supplied topology.
Node attestation, when receipt signatures verify.
Resource-safety validation reported by the governed verifier.
That the supplied stateHash string remained protected inside the signed bundle.

What this does not prove

That a producer's state preimage was complete or truthful.
That stateHash was recomputed by the Node.
That signals.governanceSignature authenticates the producer.
That a model output was correct, safe, fair or compliant.
That an authenticated attestation is automatically public.