Faramesh Core Specification v1.0 (Alignment)

The Faramesh Core Specification v1.0 (Normative) defines interoperable semantics for execution-time authorization of agent tool calls. It is published under:

DOI: 10.5281/zenodo.18371591
Title: Faramesh Core Specification v1.0 (Normative)
Author: Amjad Fatmi

Full systems approach paper — https://www.arxiv.org/abs/2601.17744

This document summarizes how the Faramesh Horizon implementation aligns with that spec and notes any intentional differences or extensions.

Scope of the spec

The spec defines:

Canonical Action Representation (CAR) — Normalized action used for evaluation and hashing
Hashing — request_hash (SHA-256 of canonical CAR), optional state_hash, hash stability
Execution profiles — Optional allowlist and constraints
Policy program — First-match-wins, default deny, match predicates, policy_hash
Risk scoring — Independent evaluation, first-match-wins, high-risk upgrade (EXECUTE → ABSTAIN)
Fail-closed semantics — Ambiguity or error → HALT
Decisions and lifecycle — EXECUTE / ABSTAIN / HALT; status values; state machine; non-bypassability
Decision Provenance Records (DPR) — Append-only, hash-chained, with seq/namespace
HTTP API — Submit, get, list, events, approval, start, result, health, metrics
Replay — Deterministic re-evaluation without execution
MGRP-1 — Minimal Gate Runtime Profile (optional conformance)

Alignment summary

Spec area	Implementation alignment
Action (external)	Action submission uses `agent_id`, `tool`, `operation`, `params`, `context` (context optional, default `{}`).
CAR	Decision engine builds CAR with exactly the five keys; canonicalization excludes server-computed fields and sorts keys lexicographically.
request_hash	SHA-256 of canonical JSON of CAR; lowercase hex. Hash stability: same CAR ⇒ same hash.
policy_hash	Computed from normalized policy program; bound to every decision.
profile_hash	Computed when profiles are used; otherwise `"0"*64` per spec.
Decisions	EXECUTE, ABSTAIN, HALT. First-match-wins policy; default deny when no rule matches.
Risk	Risk rules evaluated independently; first-match-wins. High-risk upgrade: if policy would allow but risk is high, outcome is ABSTAIN (require approval).
Fail-closed	Parse/schema errors, missing policy, internal errors → HALT. No execution without explicit allow/approval.
Lifecycle	Status values include pending_decision, allowed, denied, pending_approval, approved, executing, succeeded, failed (and timeout). Transitions enforce: no execution until approved (or allowed for immediate EXECUTE).
Provenance	Each action stores `request_hash`, `policy_hash`, `profile_hash`, `provenance_id`, `runtime_version`. Event log is hash-chained (`prev_hash`, `record_hash`) for tamper-evident audit.
API	POST/GET /v1/actions, GET /v1/actions/{id}/events, POST /v1/actions/{id}/approval, POST /v1/actions/{id}/start, POST /v1/actions/{id}/result, /health, /ready. List supports filtering.
Replay	Deterministic replay supported (CLI and/or HTTP). Re-evaluation uses same CAR and policy/profile versions; no side effects.

Optional / extension points

op alias: Spec allows normalizing op → operation and rejects if both are present. The API may require operation explicitly; clients should send operation for compatibility.
DPR structure: Spec defines a single DPR per decision with seq, namespace, and full hash chain. This implementation uses hash-chained action_events plus version-bound fields on the action row; the same provenance guarantees are met for audit and replay.
Execution profiles: Supported; when disabled, profile_id is null and profile_hash is zero.
MGRP-1: Optional. A minimal gate can expose a single decide-only interface and satisfy MGRP-1 by not performing execution.

Conformance tests (spec §17)

The spec requires tests for:

Canonicalization and hashing (key order, context default, alias, determinism)
Policy semantics (first-match-wins, default deny)
Risk override (high-risk upgrade)
Fail-closed semantics
Lifecycle (approval gating, invalid transitions, result reporting)
DPR integrity (append-only, hash chain, monotonic seq)

Implementations should run a conformance test suite that covers these; see the spec for the exact checklist.

References

Faramesh Core Specification v1.0 (Normative) — https://doi.org/10.5281/zenodo.18371591
Full systems approach paper — https://www.arxiv.org/abs/2601.17744
RFC 2119 — Key words for use in RFCs (MUST, SHOULD, etc.)
Concepts and deep dives — Authorization boundary, Execution gate, CAR, Provenance, Security & compliance

Table of content