GRACE Protocol Specification v1.0

Official Title: Verifiable Agentic Prompt Architecture (VAPA)
Status: Published
Version: 1.0
Date: 2026-04-07
Reference Implementation: STRATT (Stratum) v2.0+

Executive Summary

GRACE defines the discipline of constructing, versioning, fingerprinting, and auditing prompt units such that every execution is cryptographically traceable to an approved, immutable specification. This specification consists of five normative layers:

Layer	Name	Purpose	Implementation
SPEC-01	Prompt Contract Specification	Unit types, typed contracts, change classification	@stratt/schema
SPEC-02	Blake3 Fingerprint & Tamper Detection	Cryptographic integrity verification	@stratt/fingerprint
SPEC-03	Dependency Graph Specification	Import DAG, blast radius, cycle detection	@stratt/graph
SPEC-04	Gate Checkpoint Protocol	Synchronisation primitives, audit records	@stratt/graph + @stratt/cli
SPEC-05	Execution Trace & Audit Specification	Mandatory traces, quality scoring, DSPy export	(design phase)

SPEC-01: Prompt Contract Specification

Overview

SPEC-01 addresses silent contract drift: units change output shapes without detection, causing downstream failures in autonomous chains. This specification defines five unit types with typed input/output contracts, failure mode declarations, and automated change classification.

1.1 Unit Types

Five canonical unit types exist in the GRACE protocol. All units are identified by the URI format: stratt://{domain}/{type}/{slug}@{version}.

1.1.1 Role

A role defines the persona and capabilities of an agent within a chain.

Schema (packages/schema/src/types/role.ts):

type: "role"
domain: Domains (15 values)
slug: string (lowercase, alphanumeric + hyphens)
version: semver
summary: string
read_when: string (optional)
lens: string (required) — Agent's perspective/viewpoint
tone: string (required) — Communication style
behaviours: string[] (required) — Specific actions the role takes
output_format: string (required) — Expected output structure
fingerprint: blake3:{64 hex}

Example: stratt://dev/role/code-reviewer@1.2.3 — A code review agent with specific lens, tone, and output expectations.

1.1.2 Rule

A rule defines a constraint or policy that applies within a specific scope.

Schema (packages/schema/src/types/rule.ts):

type: "rule"
domain: Domains
slug: string
version: semver
summary: string
read_when: string (optional)
polarity: "always" | "never" (required)
statement: string (required) — The constraint condition
scope: "global" | "domain" | "chain" | "session" (required)
protected: boolean (optional)
fingerprint: blake3:{64 hex}

Example: stratt://dev/rule/no-hardcoded-secrets@1.0.0 with polarity: "never" and scope: "global".

1.1.3 Task

A task defines a discrete unit of work with a typed contract and execution context.

Schema (packages/schema/src/types/task.ts):

type: "task"
domain: Domains
slug: string
version: semver
summary: string
read_when: string (optional)
contract: Contract (required)
council: string (required) — Council authority
prompt_body: string (required) — Prompt text
fingerprint: blake3:{64 hex}

Example: stratt://ops/task/health-check@2.1.0 with inputs {service: string} and outputs {status: "ok"|"error", message: string}.

1.1.4 Chain

A chain composes multiple units into an orchestrated workflow.

Schema (packages/schema/src/types/chain.ts):

type: "chain"
domain: Domains
slug: string
version: semver
summary: string
read_when: string (optional)
contract: Contract (required)
council: string (required)
composition: Composition[] (required) — Ordered steps
fingerprint: blake3:{64 hex} (Merkle root of step fingerprints)

Example: stratt://dev/chain/code-review-workflow@1.5.0 with steps for analysis, review, approval.

1.1.5 Supply

A supply provides external data or configuration to chains.

Schema (packages/schema/src/types/supply.ts):

type: "supply"
domain: Domains
slug: string
version: semver
summary: string
read_when: string (optional)
supply_body: string (required) — Data payload
fingerprint: blake3:{64 hex}

Example: stratt://shared/supply/security-policies@1.0.0.

1.2 Contract Model

All tasks and chains define typed input/output contracts to prevent silent drift.

Schema (packages/schema/src/types/contract.ts):

Contract {
  inputs: Input[] where Input = {
    name: string
    type: InputType (7 values: string, integer, float, boolean, document, array, object)
    required: boolean
    description: string
  }
  outputs: Output[] where Output = {
    name: string
    type: OutputType
    description: string
  }
  failure_modes: FailureMode[] where FailureMode = {
    code: string
    handler: "gate" | "retry" | "abort" | "fallback"
    description: string
    escalation: string (optional)
  }
}

Conformance: Contract modifications that add outputs or make inputs optional are non-breaking (minor/patch). Removals or type changes are breaking (major).

1.3 Lifecycle State Machine

Units progress through a 9-state lifecycle with explicit state transitions and merge ordering (CRDT).

States (packages/schema/src/constants.ts):

draft — Under development, not shared
review — Submitted for peer review
approved — Review passed, ready to publish
published — Published to R2 registry
active — Production use enabled
deprecated — Superseded but still usable
archived — No longer usable, retained for audit
tombstoned — Deleted, cannot be imported
tampered — Failure state (fingerprint mismatch)

Valid Transitions (packages/schema/src/lifecycle.ts lines 57-100):

draft → review, draft
review → draft, approved, review
approved → review, published
published → active, deprecated, published
active → deprecated, active
deprecated → published, archived, tombstoned, deprecated
archived → deprecated, tombstoned, archived
tombstoned → tombstoned
tampered → draft

Gate-Required Transitions (Frozen transitions requiring SPEC-04 approval):

approved → published
active → deprecated
archived → tombstoned
deprecated → tombstoned

1.4 Draft Isolation Rule (FM-07)

A unit in draft status can only import units also in draft status. This prevents immature work from polluting approved chains.

Import Permission Matrix (packages/schema/src/lifecycle.ts lines 129-173):

Importer Status | Can Import drafts? | Can Import review? | Can Import approved+ ?
draft           | YES                | NO                 | NO
review          | YES                | YES                | NO
approved+       | NO                 | NO                 | YES
deprecated      | NO                 | NO                 | YES
archived        | NO (always blocked)

Units in tombstoned or tampered status can never be imported.

1.5 Domains

Fifteen domains segment the unit ecosystem:

Core Domains (4): dev, ops, docs, shared
Professional Domains (11): neuro, finance, nutrition, legal, film, artist, security, product, data, marketing, core

Cross-Domain Import Rule: Non-shared domains may only import from core/ or shared/ except within their own domain.

1.6 Validation Pipeline

Units must pass a 6-step validation pipeline before acceptance:

Zod Schema Validation: All fields conform to type schema
URI Validation: stratt://{domain}/{type}/{slug}@{version} format, domain and type must exist
Import Validation: All imported units exist and are addressable
Draft Isolation (FM-07): Importer status permits imported unit status
Lifecycle Validation: Current status has valid transitions available
Forbidden Block Detection: Detects and prevents problematic patterns (e.g., cycles via imports)

Implementation: packages/schema/src/validate.ts lines 1-122.

1.7 Councils and Gate Authority

Units are stewarded by councils that grant execution permissions.

Council Schema (packages/schema/src/types/council.ts):

Council {
  name: string (dev, ops, docs, security, product, data, marketing)
  gate_authority: Agent — Single agent with approval power
  protected_agents: Agent[] — Agents that cannot be bypassed
  agents: Agent[] where Agent = {
    designation: string (e.g., "LEWIS-06")
    role: string
    capabilities: Capabilities[] (11 values: analysis, architecture, audit, code, data, domain, gates, memory, operations, planning, write)
    protected: boolean
  }
}

7 Active Councils:

Council	Gate Authority	Protected Agent(s)	Domain
Pathfinder	LEWIS-06	BECK-02	dev
Hermes	RETRO-04	EECOM-02	ops
Athena	EDITOR-04	CURATOR-02	docs
Bastion	COMMANDER-05	ANALYST-03	security
Compass	COURSE-05	MERIDIAN-03	product
Herald	CROWN-05	GAZETTE-03	marketing
Terra	MANTLE-05	SPRING-03	data

SPEC-02: Blake3 Fingerprint & Tamper Detection

Overview

SPEC-02 addresses unverifiable execution: no way to verify that the prompt executing in production is the one that was authored, reviewed, and approved. This specification defines cryptographic fingerprinting via Blake3 hashing over canonical YAML serialisation.

2.1 Canonical Serialisation Pipeline

The fingerprinting process follows a strict 5-stage pipeline to ensure deterministic hashes regardless of YAML encoding variations.

Stage 1: YAML Parsing

Parse input as YAML 1.2 core schema with:

version: 1.2
schema: core
merge: true
uniqueKeys: true

Source: CANONICAL-SERIALISATION-SPEC.md lines 88-143.

Stage 2: Object Transformation

Three sequential sub-stages:

2a. Field Exclusion: Remove the fingerprint key from all objects (it is stored separately).

2b. Null Removal: Recursively remove all null values from objects. Preserve empty arrays [] and empty objects {}.

2c. Unicode NFC Normalisation: Normalise all strings to NFC (composed form) using Unicode canonical composition. This prevents equivalent but differently-encoded strings from producing different hashes.

Source: packages/fingerprint/src/canonicalise.ts lines 5-46.

Stage 3: Canonical JSON Serialisation

Produce compact JSON with recursive key sorting in UTF-16 order:

Recursively sort all object keys in UTF-16 lexicographic order
Serialize to JSON without whitespace
No trailing newline

Source: packages/fingerprint/src/canonicalise.ts lines 34-46.

Stage 4: UTF-8 Encoding

Encode the canonical JSON string as UTF-8 bytes:

No BOM
No trailing newline
1 byte per ASCII character

Source: packages/fingerprint/src/canonicalise.ts line 65.

Stage 5: Blake3 Hashing

Hash the UTF-8 bytes using Blake3:

Algorithm: Blake3 (256-bit hash)
Output: 64 hexadecimal lowercase characters
Storage format: blake3:{hex} (the blake3: prefix is metadata; only the hex is stored in SPUH)

Source: packages/fingerprint/src/hash.ts lines 10-15.

2.2 Chain Fingerprints (Merkle Tree)

Chain fingerprints are computed as Merkle tree roots of step fingerprints:

chain_fingerprint = blake3(
  sorted_step_fingerprints +
  chain_metadata
)

This ensures that modifying any step changes the chain fingerprint, enabling blast radius detection.

2.3 Verification Process

The verification process compares stored vs. computed fingerprints.

Verification States:

export type VerifyStatus =
  | "verified"   — Computed matches stored
  | "tampered"   — Computed differs from stored
  | "error"      — Parsing or hashing failed

Verification Algorithm (packages/fingerprint/src/verify.ts lines 10-54):

Extract stored fingerprint from object
Compute fingerprint over object (without the fingerprint field)
Compare stored to computed
If equal, return { status: "verified", ... }
If not equal, return { status: "tampered", ... } with mismatch position
If any error occurs, return { status: "error", ... }

2.4 RFC 8785 (JCS) Divergence Analysis

This specification intentionally diverges from RFC 8785 in 4 areas:

Divergence	RFC 8785	GRACE	Rationale
Input Format	JSON only	YAML then convert	YAML is author-friendly; conversion is deterministic
Pre-processing	None required	3-stage transformation	Null removal + NFC prevent encoding ambiguity
Unicode Handling	NFD (decomposed)	NFC (composed)	NFC is more common; neither affects semantics
Null Handling	null → `"null"` string	null → removed	Empty structures `[]` `{}` are semantically distinct from null

Complete analysis: CANONICAL-SERIALISATION-SPEC.md lines 329-356.

2.5 Test Vectors

Fourteen normative test vectors validate canonical serialisation implementations.

Vector Categories:

TV-01 to TV-05: Minimal units (one of each type: role, rule, task, chain, supply)
TV-06 to TV-10: Edge cases (empty arrays, block scalars, unicode, absent fields)
TV-11 to TV-14: Complex (nested imports, 6-step chain, NFC equivalence, key sort stress)

Format of Each Vector:

input:
  # Original YAML
canonical_json: |
  # Expected canonical JSON (no whitespace, keys sorted)
blake3_digest: blake3:...

Location: CANONICAL-SERIALISATION-SPEC.md lines 456-1087.

Conformance Requirement: All 14 vectors must be processed identically by any GRACE implementation.

2.6 Implementation Checklist

YAML parser with 1.2 core schema, merge enabled
Recursive null removal (preserve [] and {})
NFC normalisation for all strings
Recursive key sorting (UTF-16 order)
Compact JSON serialisation
Blake3 hashing (blake3-wasm v2.1.5 pinned)
Stored vs. computed comparison
All 14 test vectors pass

SPEC-03: Dependency Graph Specification

Overview

SPEC-03 addresses cascade failures: modifying a core unit without knowing it’s imported by dozens of other units causes silent failures. This specification defines a directed acyclic graph (DAG) model for unit imports, cycle detection, and blast radius computation.

3.1 Import Declarations

Units declare imports using URI references: stratt://domain/type/slug@version or choco://namespace/path@version.

In Task/Chain Composition:

type: chain
composition:
  - id: "step_1"
    unit: stratt://dev/role/code-reviewer@1.2.3
    agent: LEWIS-06
    depends_on: []
  - id: "step_2"
    unit: stratt://dev/task/review-code@1.0.0
    agent: BECK-02
    depends_on: ["step_1"]

In Rules/Roles/Supplies:

imports:
  - stratt://core/rule/no-secrets@1.0.0
  - stratt://shared/supply/policies@2.0.0
  - choco://neuro-research/protocol/ethics@3.1.0

3.2 DAG Construction

The dependency graph is built by:

Enumerating all units in the registry
For each unit, parsing its imports
Creating directed edges: unit → imported_unit
Running cycle detection (Kahn’s algorithm)

Cycle Detection (packages/graph/src/dag.ts):

function hasCycle(edges: Set<[from, to]>): boolean {
  const inDegree = computeInDegrees(edges)
  const queue = [all nodes with inDegree 0]
  while (queue.length > 0):
    current = queue.shift()
    for each edge (current → neighbor):
      inDegree[neighbor]--
      if inDegree[neighbor] == 0:
        queue.push(neighbor)
  return (unvisited nodes with inDegree > 0) ? true : false
}

Failure Mode FM-03 is triggered if cycles are detected.

3.3 Blast Radius Computation

The blast radius of a unit is the set of all units that transitively depend on it.

Algorithm:

function blastRadius(unit: Unit): Set<Unit> {
  result = { unit }
  visited = {}
  queue = [unit]
  while queue not empty:
    current = queue.shift()
    visited.add(current)
    for each unit u that imports current:
      if u not in visited:
        result.add(u)
        queue.push(u)
  return result
}

Use: When publishing unit v2.0.0 with breaking changes, blast radius tells you which units must also be re-published.

3.4 Domain Isolation

Cross-domain imports are restricted to prevent tight coupling:

Rule: Non-shared domains may only import from core/ or shared/ unless importing within their own domain.

dev/task/*       → can import from: dev/*, core/*, shared/*
ops/role/*       → can import from: ops/*, core/*, shared/*
docs/chain/*     → can import from: docs/*, core/*, shared/*

Violations trigger a validation error.

3.5 Cross-Namespace Resolution

The choco:// URI scheme enables imports from the Choco HQ documentation engine (cross-namespace):

stratt://dev/task/extract-docs@1.0.0 imports:
  - choco://security/standards/data-handling@2.1.0

Resolution: ChocoBridgeResolver (packages/graph/src/choco-resolver.ts) maps choco:// URIs to HTTP endpoints.

3.6 Failure Modes

Code	Name	Trigger	Handler
FM-02	Broken Imports	Imported unit doesn’t exist	Validation error, reject publish
FM-03	DAG Cycles	Circular dependency detected	Validation error, reject publish
FM-07	Draft Isolation	Draft imports non-draft	Validation error (SPEC-01)

SPEC-04: Gate Checkpoint Protocol

Overview

SPEC-04 addresses undetectable degradation: autonomous chains produce plausible-looking output that is subtly wrong, with no detection mechanism. This specification defines synchronisation primitives (hard gates) that halt execution, requiring explicit human or agent approval.

4.1 Gate Architecture

Gates are synchronisation checkpoints that halt chain execution completely until resolved.

Gate Resolution States:

PENDING (default)
├── APPROVED (by gate authority)
├── REJECTED (by gate authority)
├── TIMEOUT (24h default, escalates to Veritas)
└── ESCALATED (to higher council)

Gate Authority: Each council has a single gate authority agent (e.g., LEWIS-06 for Pathfinder).

Protected Agents: Some agents cannot be bypassed by gates. Their steps always execute if contract is satisfied. Protected agents per council:

Pathfinder: BECK-02
Hermes: EECOM-02
Athena: CURATOR-02
Bastion: ANALYST-03
Compass: MERIDIAN-03
Herald: GAZETTE-03
Terra: SPRING-03

4.2 Gate Marking in Composition

Composition steps can be marked with gate: true:

composition:
  - id: "analyze"
    unit: stratt://dev/task/analyze-code@1.0.0
    agent: LEWIS-06
    gate: false
  - id: "approve_changes"
    unit: stratt://dev/task/approve-changes@2.0.0
    agent: LEWIS-06
    gate: true      # Requires approval
    depends_on: ["analyze"]

4.3 Gate-Required Transitions

Four lifecycle transitions require gate approval (SPEC-04 enforcement):

approved → published (promotion to production readiness)
active → deprecated (removal from production)
archived → tombstoned (permanent deletion)
deprecated → tombstoned (permanent deletion from deprecated)

Audit Record: Every gate resolution is recorded with timestamp, resolver agent, and reason.

4.4 Councils

Seven councils govern different domains:

Pathfinder:
  domain: dev
  gate_authority: LEWIS-06
  protected: [BECK-02]
  agents: [LEWIS-06, BECK-02, ALPHA-01, GAMMA-03, ...]

Hermes:
  domain: ops
  gate_authority: RETRO-04
  protected: [EECOM-02]
  agents: [RETRO-04, EECOM-02, ...]

[5 more councils]

Configuration: councils/{name}/council.yaml (verified to exist for all 7).

4.5 Failure Modes

Code	Name	Trigger	Handler
FM-04	Protected Agent Missing	Unit assigned to protected agent, but agent doesn’t exist in council	Validation error, reject step
FM-05	Gate Removal	Gate-required transition attempted without gate authority approval	Validation error, block transition
FM-09	Capability Check	Agent lacks required capability for step	Validation error, reject assignment

SPEC-05: Execution Trace & Audit Specification

Overview

SPEC-05 addresses unquantified improvement: after months of running chains, no way to answer which units improved, which degraded, which gates fired most often. This specification defines mandatory trace creation, quality scoring, and automated regression detection.

Status: Design phase. Implementation in grace/automation/trace-protocol.md. Not yet in STRATT packages.

5.1 Trace Model

Every chain execution produces a trace record.

Chain-Level Trace:

trace_id: string (UUID)
chain_address: stratt://domain/chain/slug@version
version: semver
fingerprint: blake3:...
session_id: string (optional, groups related executions)
created_at: ISO8601 timestamp
completed_at: ISO8601 timestamp
status: "success" | "partial" | "failed" | "timeout"
quality_score: number (0.0–1.0)
token_count:
  input: integer
  output: integer
  total: integer

Step-Level Trace (array):

steps:
  - unit_address: stratt://...
    agent: string (e.g., LEWIS-06)
    prompts_sent: number
    responses_received: number
    tokens_in: integer
    tokens_out: integer
    status: "pending" | "in_flight" | "completed" | "error" | "gated"
    gate_resolution: "approved" | "rejected" | "timeout" | "escalated" (optional)
    quality_delta: number (-1.0–1.0, relative to baseline)

5.2 Quality Scoring

Quality is computed via a pluggable scorer interface with a heuristic default.

Heuristic Scorer (grace/automation/trace-protocol.md):

quality_score = (
  0.5 * conformance_score +    // Does output match contract?
  0.3 * completeness_score +   // Are all required fields present?
  0.2 * efficiency_score       // Tokens per unit output
)

5.3 DSPy Export

Traces are exported as JSONL for DSPy optimization:

{"example": "input", "prediction": "output", "score": 0.92, "trace_id": "..."}

Filtering by:

Minimum score (e.g., score ≥ 0.8)
Date range
Version range
Unit address pattern

5.4 Regression Detection

Automated detection when quality score degrades by > 5% (configurable):

if (new_score - baseline_score) < -0.05:
  trigger Veritas gate for manual review

Failure Modes Reference (FM-01 through FM-09)

All failure modes are enumerated and traceable to implementation files.

Code	Name	Spec	Trigger Condition	Implementation	Handler
FM-01	Fingerprint Tamper	SPEC-02	Stored fingerprint ≠ computed fingerprint	`packages/fingerprint/src/verify.ts`	Reject execution, alert ops
FM-02	Broken Imports	SPEC-03	Referenced unit doesn’t exist or is unresolvable	`packages/graph/src/resolve.ts`	Validation error, block publish
FM-03	DAG Cycles	SPEC-03	Circular dependency detected	`packages/graph/src/dag.ts`	Validation error, block publish
FM-04	Protected Agent Missing	SPEC-04	Step assigned to protected agent not in council	`packages/graph/src/protect.ts`	Validation error, block step
FM-05	Gate Removal	SPEC-04	Gate-required transition without approval	`packages/graph/src/protect.ts`	Validation error, block transition
FM-06	Contract Breaking Change	SPEC-01	Required input removed or type changed without major bump	`packages/graph/src/protect.ts`	Validation error, block publish
FM-07	Draft Isolation	SPEC-01 + SPEC-03	Draft imports non-draft unit	`packages/schema/src/lifecycle.ts` + `packages/graph/src/protect.ts`	Validation error, block import
FM-08	R2 Infrastructure Failure	(Infrastructure)	Registry unavailable, network error, auth failure	(R2 layer)	Publish fails, rollback
FM-09	Capability Check	SPEC-01	Agent lacks required capability for step	`packages/graph/src/protect.ts`	Validation error, block assignment

URI Scheme Specification

STRATT URIs

Format: stratt://{domain}/{type}/{slug}@{version}

Components:

Part	Pattern	Example	Notes
scheme	`stratt://`	`stratt://`	Literal prefix
domain	`(dev\|ops\|docs\|...)`	`dev`	15 valid domains
type	`(role\|rule\|task\|chain\|supply)`	`task`	5 unit types
slug	`[a-z0-9-]+`	`code-reviewer`	Lowercase, hyphens allowed
version	`\d+\.\d+\.\d+`	`1.2.3`	Semantic versioning

Full Regex:

^stratt://(dev|ops|docs|neuro|finance|nutrition|legal|film|artist|security|product|data|marketing|core|shared)/(role|rule|task|chain|supply)/([a-z0-9-]+)@(\d+\.\d+\.\d+)$

CHOCO URIs

Format: choco://{namespace}/{path}@{version}

Used for cross-namespace imports from Choco HQ documentation engine.

Example: choco://security/standards/data-handling@2.1.0

Conformance Levels

Three conformance levels define implementation completeness:

Level 1: Core (Minimum)

Mandatory for any GRACE implementation:

SPEC-01 unit types and contracts
SPEC-02 fingerprinting (Blake3)
SPEC-03 DAG cycle detection
Validation pipeline (all 6 steps)

Reference: @stratt/schema + @stratt/fingerprint + @stratt/graph (basic cycle detection)

Level 2: Production (Recommended)

For production deployments:

Reference: Full STRATT implementation (@stratt/cli, @stratt/graph with all modules)

Level 3: Advanced (Optional)

For organisations requiring complete observability:

Reference: STRATT + SPEC-05 implementation (future).

Design Principles

1. Determinism

All cryptographic operations must be deterministic. Given identical input, implementations must produce identical output. The 5-stage fingerprint pipeline enforces this through canonical serialisation.

2. Immutability

Published units (status ≥ published) are immutable. Modification requires publishing a new version. This enables reliable dependency tracking and blast radius computation.

3. Auditability

Every mutation, gate resolution, and state transition is recorded with timestamp and resolver. No silent changes.

4. Fail Secure

When in doubt, reject. All 9 failure modes result in explicit rejection with clear error messages, never silent acceptance.

5. Layering

Implementation is strictly layered. Lower layers (fingerprint, schema) have zero knowledge of higher layers (CLI, IR, N8n exporters). Enables independent development and testing.

Implementation Packages (STRATT v2.0+)

Package	Layer	Purpose	Normative Specs
@stratt/fingerprint	L0	Canonical serialisation, Blake3 hashing	SPEC-02
@stratt/schema	L1	Zod validators, URI parsing, SPUH encoding	SPEC-01
@stratt/crdt	L2	CRDT merge strategies (7 strategies)	—
@stratt/graph	L3	DAG, blast radius, CI pipeline, gates	SPEC-03, SPEC-04
@stratt/ir	L4	Execution IR, portable compilation	—
@stratt/n8n-exporter	L3.5	Chain → n8n workflow compiler	—
@stratt/cli	L5	21 commands, orchestration	All specs
MERIDIAN	L6	Astro documentation site	—

Verification Checklist

References

Primary sources (all locations verified as of 2026-04-07):

SPEC-01: ~/code/workspace/stratt-hq/packages/schema/src/ (14 files, 673 lines)
SPEC-02: ~/code/workspace/stratt-hq/CANONICAL-SERIALISATION-SPEC.md (1,215 lines)
SPEC-03: ~/code/workspace/stratt-hq/packages/graph/src/ (dag.ts, resolve.ts, blast.ts, protect.ts, choco-resolver.ts)
SPEC-04: ~/code/workspace/stratt-hq/councils/ (7 YAML files), packages/graph/src/protect.ts
SPEC-05: ~/code/workspace/grace/automation/trace-protocol.md (design phase)

Related documents:

GRACE Protocol Overview: ~/code/workspace/grace/architecture/GRACE-PROTOCOL-OVERVIEW.md
CLAUDE.md (workspace guide): ~/code/workspace/grace/CLAUDE.md

Revision History

Version	Date	Changes	Author
1.0	2026-04-07	Initial publication (reverse-engineered from STRATT v2.0+)	OpenCode Agent

License

This specification is published under the VAPA (Verifiable Agentic Prompt Architecture) protocol. Reference implementation is STRATT.

Published: grace.devarno.cloud/protocol/specification