Governed Execution Verification Semantics
Which Node routes attest, verify statelessly or publish keys, what each one persists or signs, and how receipt and envelope signatures set the trust boundary.
Route matrix
| Surface | Authentication | Persists | Signs | Intended use |
|---|---|---|---|---|
POST /api/attest | Yes | Yes, default hidden | Yes | Authenticated attestation; body is the sealed CER |
POST /v1/cer/verify | No | No | No (checks a supplied envelope only) | Stateless verification; body { bundle } |
GET /.well-known/nexart-node.json | No | No | No | Node identity and key discovery |
GET /health | No | No | No | Operational health |
GET /version | No | No | No | Node and SDK version discovery |
POST /api/proofs/:certificateHash/unhide | Yes, owner | Updates visibility | No | Local hidden to public; certificate hash unchanged |
Unsupported routes
/certifyDecision, /verify/{hash} and /v1/attestation/cage-governance are not registered Node routes. Do not confuse an SDK helper named certifyDecision, a Node HTTP route, a portal route on verify.nexart.io, an authenticated attestation and a stateless verification call.
Version discovery
GET /version (governed fields)
{
"serviceVersion": "0.30.1",
"governedExecutionSdkVersion": "0.4.2"
}Deployment build metadata such as serviceBuild may also be present.
Transport status versus verdict
HTTP 200 from /v1/cer/verify means verification completed. The body's status (verified or failed), reasonCode and per-layer checks determine whether the CER passed.
Receipt and envelope trust boundaries
See also Verification Semantics and Independent Verification.