OrgForge is designed as infrastructure. The development follows a deliberate sequence. Prove the primitive. Decentralize the network. Open the ecosystem.

Phase	Description	Status
Phase 0	Authorization engine. Single-org demo. 25/25 tests.	Complete
Phase 1	Policy enforcement proxy for AI agent tool calls.	Building
Phase 2	Policy engine. On-chain OrgSpec registry. Multi-org.	~12 months
Phase 3	Org operating system. Full lifecycle. AI coordination.	~24 months

Phase 0: Authorization Engine (Complete)

The core primitive is operational. Actors submit intents. Validators evaluate against an OrgSpec. A 2-of-3 threshold-signed authorization proof is assembled. Execution systems verify the proof before acting. 25/25 test assertions passing.

Phase 1: Governance Firewall (Building)

Policy enforcement proxy for AI agent tool calls. The MCP proxy adapter intercepts tool calls from AI agents, constructs OrgForge intents, evaluates them against an OrgSpec, and gates execution. Authorized actions proceed. Rejected actions are blocked and logged. The adapter holds the keys. The agent never does.

Phase 2: Policy Engine (~12 months)

The validator network decentralizes. Multiple independent operators run validator nodes. Multi-organization support ships. Each org maintains its own OrgSpec on-chain. The protocol becomes shared public infrastructure rather than a hosted service.

Phase 3: AI Coordination Layer (~24 months)

OrgForge becomes the governance substrate for autonomous agent ecosystems. AI agents operating across organizations carry authorization proofs as first-class primitives. The original vision becomes buildable on top of OrgForge. Decentralized organizations capable of executing on global-scale coordination.

OrgSpec Schema

An OrgSpec is a machine-readable organizational constitution. It defines roles, actors, and the policy rules governing each action type. The demo OrgSpec encodes three roles across three actors.

{
  "org_id": "org:demo",
  "orgspec_version": "v0",
  "roles": {
    "trader_agent": {
      "allowed_action_types": ["PLACE_ORDER"],
      "allowed_markets": ["ETH-USD", "BTC-USD"],
      "max_order_notional_usd": 10000,
      "approval_threshold_usd": 10000
    },
    "trainer_agent": {
      "allowed_action_types": ["TOOL_CALL"],
      "allowed_tools": ["search", "summarize", "draft", "code_exec"],
      "requires_approval": ["code_exec"]
    }
  },
  "actors": {
    "agent:trader_1": { "role": "trader_agent", "active": true },
    "agent:trader_suspended": { "role": "trader_agent", "active": false }
  }
}

Authorization Pipeline

Every intent passes through five deterministic stages. A failure at any stage produces a rejection with a specific reason code. No stage can be skipped. No override path exists.

Stage 1: Intent Structure

Validates that all required fields are present: org_id, actor_id, action_type, params, nonce, expires_at. Structural failures reject immediately.

Stage 2: Actor and Role

Looks up the actor in the OrgSpec. Verifies the actor is active. Resolves the actor's role. Suspended actors are rejected regardless of the action.

Stage 3: Intent Freshness

Checks that expires_at is in the future. Expired intents are rejected even if they would otherwise be authorized.

Stage 4: Action Policy

Evaluates the action-specific constraints defined in the role. For PLACE_ORDER: allowed markets, per-order notional limit. For TOOL_CALL: allowed tools list.

Stage 5: Approval Gate

Checks whether the action requires human approval. If requires_approval includes the tool, or if the notional exceeds approval_threshold_usd, the intent must include approvals.approvals_met: true.

Reason Codes

Code	Meaning
OK	Authorization successful
ERR_EXPIRED_INTENT	Intent expiry is in the past
ERR_UNKNOWN_ACTOR	actor_id not found in OrgSpec
ERR_SUSPENDED_ACTOR	Actor exists but active: false
ERR_ROLE_NOT_FOUND	Actor's role not defined
ERR_ACTION_NOT_ALLOWED	Role does not permit this action_type
ERR_TOOL_NOT_ALLOWED	Tool not in role's allowed_tools
ERR_MARKET_NOT_ALLOWED	Market not in role's allowed_markets
ERR_MAX_ORDER_EXCEEDED	Notional exceeds max_order_notional_usd
ERR_APPROVAL_REQUIRED	Action requires approval. None provided.
ERR_INVALID_PARAMS	Required params missing or malformed
ERR_REPLAY	intent_hash already spent (adapter-local)
ERR_PROOF_EXPIRED	Authorization proof has expired
ERR_PROOF_MISMATCH	Proof does not match this intent
ERR_INTERNAL	Internal error

Glossary

Intent

A signed, structured proposal submitted by an actor describing a proposed action. Contains: org_id, actor_id, action_type, params, nonce, expires_at.

OrgSpec

A machine-readable organizational constitution. Defines roles, actors, and the policy rules governing each action type. The canonical governance artifact that Γ evaluates against.

Authorization Artifact

A threshold-signed proof produced by OrgForge when an intent is authorized. Bound to a specific intent hash and OrgSpec version. Expires. Cannot be transferred or reused.

Deterministic Authorization

The core primitive. Given identical (Intent, OrgSpec) inputs, Γ always produces identical outputs. Authorization is a pure function, not a policy judgment.

Validator Quorum

Phase 0 uses 2-of-3 threshold signing. Two validators must independently authorize an intent before the proof is valid. A single compromised validator cannot produce a valid proof.

Adapter

An execution-side component that verifies authorization proofs before acting. The adapter enforces: proof freshness, proof-to-intent binding, quorum threshold, and replay protection.

Replay Protection

Each intent hash can only be spent once per adapter's replay domain. Submitting the same proof a second time produces ERR_REPLAY regardless of validity.

Canonical JSON

A deterministic serialization of an intent: keys sorted lexicographically, no whitespace. The canonical form is what gets hashed. Key-order-independent. The same intent always produces the same hash.

Enforcement Boundary

The architectural requirement that no execution path exists that bypasses proof verification. OrgForge's security model is only valid if the adapter sits on the critical path before execution.