VEIP — Veraxis Execution Integrity Protocol

The Veraxis Execution Integrity Protocol (VEIP) requires cryptographic evidence of authorization to be generated before a state transition crosses a declared execution boundary. This page is the wire-level reference for the protocol as implemented at qaori.ai.

Abstract

VEIP defines a uniform evidence layer for consequential actions taken by any actor, machine or human. The instrument of compliance is the Authorization Evidence Pack (AEP), a structured record cryptographically signed before the action proceeds. Generation failure blocks the action. The signed bundle is externally verifiable: a regulator, auditor, or counterparty confirms the chain of custody and the integrity of each AEP without access to internal systems.

1. Authorization Evidence Pack

One AEP is emitted per declared execution boundary. Every field is part of the protocol wire format; implementations MUST include all fields. Reserved fields for future use MUST NOT be added in the current version.

1.1 Wire Format

Field	Type	Semantic
aep_id	string	Globally unique identifier: `aep-<uuid4-hex>`
timestamp_utc	string	RFC 3339 with microsecond precision, UTC
execution_boundary	string	Stable identifier from the boundary catalogue (§4)
evaluation_result	string	One of `PASS` / `FAIL` / `ESCALATE`
policy_artifact_id	string	Registry key for the policy in force at evaluation
policy_hash	string	SHA-256 hex digest of the policy document content
constraint_hash	string	SHA-256 hex digest of the constraint set applied
stop_right_triggered	boolean	True iff an operator halt was active at evaluation
custody_chain	list<string>	Predecessor boundary ids or AEP ids in chain order
actor_id	string	Service id or user id that performed the action
subject	string	Identifier of the object acted on
tier	string	VEIP tier of this evidence: `R1` / `R2` / `R3`
signing_key_id	string	Identifier of the key that produced the signature
outcome	object?	Action outcome, set after the action runs; nullable
signature	string	Ed25519 signature over canonical bytes (hex)

1.2 Canonical Serialization

The bytes input to signing and verification are the JSON encoding of every AEP field except signature, with UTF-8 encoding, sorted keys at every depth, and no insignificant whitespace. This corresponds to RFC 8785 §3.2.1.

signing_input := UTF8(JSON_canonicalize(AEP \ {signature}))

Any implementation that produces bytewise-identical canonical bytes for the same AEP is interoperable with this reference implementation.

2. Signing

Each AEP is signed with Ed25519 (RFC 8032). The signature field contains the lowercase hex encoding of the 64-byte raw signature.

signature := hex( Ed25519_sign(private_key, signing_input) )

Keys are managed under signing_key_id. Key rotation publishes a new id and serves a new public key at the verification endpoint; previously-signed AEPs remain verifiable against the key id they reference.

3. Verification

The verification procedure for any third party:

Fetch the public key for the AEP's signing_key_id from a trusted endpoint (this implementation publishes it at /api/public/sentinel/public-key).
Reconstruct the canonical bytes per §1.2 from the AEP, omitting signature.
Decode the hex signature to 64 raw bytes.
Run Ed25519 verify against the canonical bytes, the signature, and the public key.
If the policy and constraint hashes are to be checked: fetch the policy and constraint set, compute SHA-256, compare.

3.1 Online (this site)

The /verify page runs the verification in your browser via WebCrypto. No data leaves your machine.

3.2 Offline (openssl)

# Fetch the public key once
curl -sS https://sentinel.qaori.ai/api/public/sentinel/public-key -o pub.pem

# Save an AEP (paste, or aws s3 cp from the vault)
# echo '{"aep_id":"aep-...","signature":"..."}' > aep.json

# Compute canonical bytes + extract signature
python -c 'import json,sys; d=json.load(open("aep.json")); sig=d.pop("signature"); \
  open("msg.bin","wb").write(json.dumps(d,sort_keys=True,separators=(",",":"))\
  .encode()); open("sig.bin","wb").write(bytes.fromhex(sig))'

# Verify
openssl pkeyutl -verify -pubin -inkey pub.pem -rawin -in msg.bin -sigfile sig.bin
# Expected: Signature Verified Successfully

4. Compliance Tiers

VEIP defines three compliance tiers, each representing a level of evidence rigor. Boundaries declare the tier they evaluate against (see §5).

Tier	Name	Required Elements
R1	Basic Execution Audit	Complete log: timestamp, actor, action, outcome. Proves what happened. Does not prove pre-authorization.
R2	Boundary-Crossing Evidence	R1 plus AEP with `policy_hash` and `evaluation_result`, generated before the action. Proves an authorization decision was made against a documented policy.
R3	Full Custody Chain with Cryptographic Verification	R2 plus Ed25519 signature, `custody_chain`, and `constraint_hash`. Externally verifiable without access to internal systems.

5. Declared Boundary Catalogue

The factory enumerates the boundaries below. Each row declares one execution boundary, the tier of evidence emitted when crossing it, and the default policy artifact evaluated against. Boundary identifiers are stable wire identifiers; regulators rely on them.

Identifier	Tier	Policy	Stop-right check	Description
loading…

6. Fail-Closed Invariant

AEP generation failure MUST block the action. This is the central invariant of the protocol and admits no exception. If the signing key is unavailable, if the evidence vault is unreachable, if the policy registry cannot resolve the artifact, the action does not proceed.

A compliance framework that permits actions when its evidence generation fails is not a compliance framework. The fail-closed invariant is what distinguishes VEIP from post-hoc audit logging.

Appendix A. Test Vector

A self-contained verification triple is available at GET /api/public/sentinel/test-vector. The response includes a known-good AEP, the canonical bytes that were signed (base64), the signature (hex), the public key (PEM), and the openssl command to confirm your toolchain against this exact triple.

Appendix B. Normative References

RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA)
RFC 8410 — Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 (PKIX)
RFC 8785 — JSON Canonicalization Scheme (JCS)
FIPS 180-4 — Secure Hash Standard (SHS)
RFC 3339 — Date and Time on the Internet