Skip to content

architecture

Intended Documentation

Architecture Overview

System components, data flow, service boundaries, and deployment topology for Intended intent verification infrastructure.

intermediate5 min readimplemented

System Overview#

Intended is a service-oriented intent verification system. It receives proposed agent actions, interprets what those actions are intended to do, verifies them against enterprise controls, issues Authority Tokens for approved actions, and records every decision in an immutable audit chain.

Core Components#

Intent Intake#

The entry point for all intent evaluation requests:

  • Request validation and authentication
  • Rate limiting and quota enforcement
  • Request routing to the verification pipeline
  • Response serialization

Authority Engine#

Evaluates verified intent against the active policy set:

  • Loads policies from the policy store at deployment time
  • Evaluates conditions against the intent context including semantic signals
  • Resolves conflicts when multiple policies match
  • Returns a deterministic decision: allow, deny, or escalate

Large Intent Model (LIM)#

Interprets raw actions into structured intent before policy evaluation:

  • Intent classification using the Open Intent Layer
  • Risk indicator extraction (sensitivity, scope, reversibility)
  • Entity extraction (resources, data categories, affected accounts)

Authority Token Service#

Issues cryptographically signed Authority Tokens:

  • Signs tokens with the tenant's private key using RS256
  • Embeds the decision, context, and evaluation metadata
  • Sets expiration and scope constraints
  • Publishes public keys for downstream verification

Audit Chain#

Records all evaluation decisions for compliance and forensics:

  • Captures the full evaluation trace: intent, policy match, decision, token
  • Writes to an append-only, hash-chained audit log
  • Supports real-time streaming and batch export
  • Enforces tenant-level data isolation

Enterprise Capability Engine#

Maps the verified intent to the enterprise capability context:

  • Resolves whether the requested action belongs to a valid business capability
  • Adds enterprise context before authority evaluation
  • Makes capability-level decisions legible to architecture and compliance teams

Policy Store#

Manages the lifecycle of governance policies:

  • Version-controlled policy storage
  • Deployment staging with approval gates
  • Rollback support with version pinning
  • Policy validation and conflict detection

Data Flow#

Intent Verification Flow#

1. Client submits proposed action --> Intent Intake
2. Intake authenticates and validates --> routes to pipeline
3. LIM interprets action into an Intent Object
4. Enterprise Capability Engine resolves business context
5. Authority Engine evaluates verified intent against active policies
6. Authority Token Service issues signed Authority Token
7. Audit Chain records the evaluation trace
8. Runtime returns the decision and token to the caller

Policy Deployment Flow#

1. Operator authors/updates policy
2. Policy Store validates and stages the change
3. Simulation engine runs impact analysis (optional)
4. Reviewer approves the deployment
5. Policy Store activates the new version
6. Policy Engine hot-reloads the active policy set
7. Audit Pipeline records the deployment event

Service Boundaries#

Trust Boundaries#

Each tenant operates within an isolated trust boundary:

  • Data isolation — tenant data is never co-mingled in storage or processing
  • Key isolation — each tenant has independent signing keys
  • Policy isolation — policies are scoped to a single tenant
  • Audit isolation — audit logs are partitioned by tenant

Network Boundaries#

  • The intent intake service is the only externally-facing service
  • Internal services communicate over authenticated gRPC
  • The Token Signing Service has no external network access
  • The Audit Pipeline writes to isolated storage per tenant

Note

The fail-closed design means that if any internal service is unreachable, the intake layer returns a deny or escalate decision rather than allowing unverified execution.

Deployment Topology#

Stateless Services#

These services scale horizontally and carry no persistent state:

  • Intent Intake
  • Large Intent Model
  • Authority Engine (loads policy set at startup and hot-reload)

Stateful Services#

These services manage persistent data:

  • Policy Store (versioned policy storage)
  • Audit Chain (append-only event log)
  • Authority Token Service (key material)

Health Checks#

Every service exposes:

  • /healthz — liveness probe (is the process running?)
  • /readyz — readiness probe (is the service ready to handle traffic?)

Security Properties#

Cryptographic Guarantees#

  • Authority Tokens are signed with RS256 keys
  • Token payloads are tamper-evident (any modification invalidates the signature)
  • Public keys are published for independent verification
  • Key rotation is supported without service interruption

Fail-Closed Default#

If any component in the evaluation pipeline fails:

  • The gateway returns a deny decision
  • The audit pipeline records the failure
  • No AI execution is authorized without an explicit allow

Audit Completeness#

Every evaluation produces an audit record, including:

  • The original intent
  • The semantic enrichment signals
  • The policy match result
  • The issued decision token
  • Timestamps and request metadata

Next Steps#