Position Paper: AIGP-Light — Graduated Governance Through Minimal Detect & Respond

SUPERSEDED: This paper represents the original design rationale (July 2026). The positioning has since evolved. AIGP-Light is now framed as AI Detect & Response — a cybersecurity discipline independent of AIGP governance. See the current paper: AI Detect and Respond — A Cybersecurity Discipline for Agentic Workloads.

The technical architecture described below remains valid. The “graduated governance” framing does not.

PRIVATE AND PROPRIETARY. Owned by Causum. See NOTICE.md.

Status: Position Paper Author: Kanjani AI Research & Causum Date: July 2026

Thesis

Not every AI deployment needs the full weight of AIGP’s 30-module governance apparatus. But every AI deployment needs basic safety — the ability to detect when a model is behaving outside acceptable bounds and respond before harm propagates.

AIGP-Light is the on-ramp: a minimal, local-first governance client that provides only detect and respond at the model call boundary. It requires no external service, no delegation tokens, no consent providers, no regulatory context modules. It is self-contained, zero-dependency governance that produces traces in the same RFC-010 §5.3 format as the full protocol.

The gap between “no governance” and “full AIGP” is where most harm occurs. AIGP-Light fills that gap — not by simplifying the protocol, but by implementing only the fragment that provides immediate safety with zero operational overhead.

The Problem: The Governance Adoption Cliff

Full AIGP Is Comprehensive — and That’s the Problem

The full AIGP Python SDK (aigp-client v5.1.0) comprises:

Module	Responsibility
`client.py` (28KB)	Core protocol client — REGISTER, CHECK, RECORD, TRACE, ANTICIPATE
`agent_client.py` (25KB)	Multi-agent orchestration, delegation chains, session linking
`trace_builder.py`	RFC-010 §5.3 span builder (stages 1–26)
`context.py`	Session context management
`delegation.py`	VLT (Verifiable Legitimacy Token) delegation
`streaming.py`	Streaming governance for token-by-token generation
`anticipation.py`	Predictive policy engine
`regulatory.py`	Base regulatory context
`african_context.py`	AU Continental AI Strategy compliance
`japanese_context.py`	Japan AI Promotion Act compliance
`tokens.py`	Token accumulation and accounting
`config.py`	Configuration management
`session.py`	Session lifecycle
`tools.py`	Tool-level governance
`govern.py`	Governance decision enforcement
`backoff.py`	Retry with exponential backoff
`providers/`	Model, consent, storage, transport provider interfaces
`schemas/geo.py`	Jurisdictional geometry for multi-regime compliance

Plus aigp-agent-core (governance lifecycle), 9 framework adapters (OpenAI, Anthropic, LangChain, CrewAI, AutoGen, LlamaIndex, Semantic Kernel, MCP, Strands), and the full Dialect/Registry system.

This is the right architecture for production agentic systems operating across jurisdictions, with delegation chains, consent requirements, and regulatory obligations. It is the full taxi service with every route, every vehicle class, every accessibility feature.

But the team that just deployed their first LLM wrapper last Tuesday? They don’t need routes to Japan. They need to know if their model is refusing 40% of queries and respond before the product manager files a bug.

The Adoption Cliff

block-beta
    columns 1
    block:full["Full AIGP"]
        A["30+ modules"] B["External services"] C["Dialects"] D["Consent / VLT"] E["Multi-agent"]
    end
    space
    block:gap["??? — Nothing exists here"]
        F["The Adoption Cliff"]
    end
    space
    block:raw["No Governance"]
        G["Raw API calls"]
    end

    style full fill:#e74c3c,color:#fff
    style gap fill:#f39c12,color:#fff
    style raw fill:#95a5a6,color:#fff

The gap between “raw API calls” and “full AIGP” is not a design flaw — it is a missing product. Teams at the bottom of this cliff face a binary choice:

Deploy ungoverned — fast, no overhead, no safety net.
Adopt full AIGP — comprehensive, but requires infrastructure, team education, operational commitment.

Most choose (1). Not because they don’t care about governance — because the step from zero to full is too steep for their current maturity. They intend to “add governance later.” Later never comes. The system is in production. Users depend on it. Adding governance becomes a retrofit, not a natural evolution.

The most dangerous AI systems are not the ones with bad governance. They are the ones with no governance — because the on-ramp didn’t exist when they needed it.

The Solution: Graduated Governance

The Governance Spectrum

Governance is not binary. It is a spectrum:

Level	What You Need	What You Get
0 — Raw	Nothing	No safety, no observability, no evidence
1 — Detect & Respond	AIGP-Light	Model-level safety, local policy enforcement, compatible traces
2 — Governed	aigp-agent-core + adapter	Full lifecycle CHECK/RECORD/TRACE against a governance service
3 — Orchestrated	Full aigp-client	Multi-agent delegation, streaming governance, anticipation
4 — Regulated	Full AIGP + Dialects	Cross-jurisdictional, multi-regime, evidence-graph-backed compliance

AIGP-Light occupies Level 1 — the first meaningful step above raw deployment. It provides:

Detection of behavioral deviation at the model call boundary
Response enforcement when deviation exceeds policy thresholds
Traces that are forward-compatible with every level above

Nothing else. No external services. No network calls to a governance application. No consent management. No delegation tokens. No regulatory context selection.

Why Level 1 Is the Critical On-Ramp

Level 1 solves the adoption cliff because:

Zero operational overhead. No governance service to deploy, no database to provision, no network dependency to monitor. AIGP-Light runs in-process, reads policy from a local YAML file.
Immediate value. Within minutes of integration, you know when your model is drifting outside acceptable behavior — and you have an automated response.
Forward-compatible. Every trace AIGP-Light emits uses the same RFC-010 §5.3 span format. When you’re ready for Level 2, your historical data is already in the right shape.
Non-invasive. The interceptor pattern wraps existing model calls. No refactoring. No new abstractions. Five lines of code.
Trust accrual starts immediately. Per the Earned Autonomy thesis — trust is earned through evidence. AIGP-Light begins producing that evidence on day one. By the time you upgrade to full AIGP, you have a trust history.

What AIGP-Light Does

Detect

AIGP-Light monitors model call behavior against configurable thresholds:

Signal	What It Measures	Example Threshold
Latency	Response time distribution	p95 > 3000ms
Refusal Rate	Model declining to answer	> 15% in 5-minute window
Topic Drift	Output diverging from expected domain	Cosine similarity < 0.6 against baseline
Confidence	Model uncertainty indicators	Mean confidence < 0.4
Token Explosion	Abnormal output length	> 3× rolling average
Error Rate	API failures and exceptions	> 5% in 1-minute window
Cost Rate	Token spend velocity	> $X per minute

Detection is statistical, not semantic. AIGP-Light does not understand what the model says — it understands how the model behaves. This is deliberate: behavioral detection is model-agnostic, framework-agnostic, and requires no ML inference of its own.

Respond

When detection signals cross configured thresholds, AIGP-Light executes a response action:

Action	What It Does	When to Use
LOG	Emit structured event, continue normally	Early warning, audit trail
ALERT	Send notification (webhook, stderr, callback)	Human needs to know
RATE_LIMIT	Throttle subsequent calls	Cost protection, abuse prevention
FALLBACK	Route to alternative model/prompt	Primary model degraded
BLOCK	Reject the call, return error	Hard safety boundary crossed
CIRCUIT_BREAK	Disable all calls for cooldown period	Systemic failure detected

Response actions are composable. A single threshold breach can trigger multiple responses (e.g., LOG + ALERT + RATE_LIMIT).

Trace

Every governed call produces a minimal trace span:

{
  "trace_id": "trc-a1b2c3d4e5f6",
  "spans": [
    {
      "stage": 9,
      "stage_name": "runtime_invocation",
      "start_time": "2026-07-11T11:00:00.123Z",
      "end_time": "2026-07-11T11:00:01.456Z",
      "duration_ms": 1333,
      "status": "OK",
      "attributes": {
        "model_id": "gpt-4o",
        "input_tokens": 1200,
        "output_tokens": 450,
        "detection": {
          "latency_p95_ms": 1333,
          "refusal": false,
          "cost_usd": 0.0023
        }
      }
    }
  ],
  "summary": {
    "total_duration_ms": 1333,
    "stages_traversed": 1,
    "slowest_stage": 9,
    "error_stages": [],
    "policy_actions": []
  }
}

This trace is a valid RFC-010 §5.3 span. It can be:

Stored locally (JSON lines, SQLite)
Forwarded to a full AIGP governance service when one is deployed
Consumed by any Receiver’s Dialect without transformation
Aggregated into the trust function from the Earned Autonomy framework

The trace format is the forward-compatibility guarantee. AIGP-Light is not a fork — it is the same protocol, emitting the same evidence, at a lower resolution.

What AIGP-Light Does NOT Do

Capability	Why Not
VLT/delegation tokens	No multi-agent delegation at Level 1. When you need chains of trust, you need full AIGP.
Regulatory contexts	No jurisdictional awareness. AIGP-Light doesn’t know about the EU AI Act or Japan AI Promotion Act. It knows about latency and refusal rates.
Consent management	No data subject consent tracking. That requires a consent provider infrastructure.
Multi-agent orchestration	No agent-to-agent governance. AIGP-Light governs a single model call boundary.
Streaming governance	No token-by-token policy enforcement. That requires the streaming module’s buffer management.
Anticipation engine	No predictive policy evaluation. AIGP-Light is reactive, not predictive.
Evidence graph	No cryptographic evidence chain. Traces are emitted, not linked into a Merkle DAG.
External service dependency	No governance application, no Mars verifier, no Dialect registry subscription. Everything runs locally.

These are not limitations — they are boundaries. Each boundary maps exactly to a capability that becomes available at the next governance level. The upgrade path is: adopt AIGP-Light → produce traces → observe behavior → decide which Level 2+ capabilities you need → adopt them incrementally.

Compatibility with the AIGP Ecosystem

The Taxi Paper’s Insight Applied

The “Not Another Taxi” paper establishes AIGP as a two-sided platform: Emitters produce evidence, Receivers evaluate it. AIGP-Light is the minimum viable Emitter — producing evidence in the correct format with zero infrastructure.

Platform Role	Full AIGP	AIGP-Light
Emitter?	Yes — full evidence stream	Yes — minimal evidence stream
Evidence format	RFC-010 §5.3	RFC-010 §5.3 (identical)
Subscribes to Dialects?	Yes — active consumption	No — but traces are Dialect-compatible
Produces trust evidence?	Yes — full posture	Yes — behavioral metrics only
Upgradeable?	N/A	Yes — traces carry forward

AIGP-Light does not participate in the Dialect marketplace actively — it does not subscribe to Receivers or consume verdicts. But its evidence output is already in the format that Receivers expect. When an AIGP-Light user upgrades to full governance, their historical traces are immediately consumable by any subscribed Dialect.

This is the platform economics at work: even the smallest emitter produces interoperable evidence. The network effect includes everyone, from day one.

The Earned Autonomy Paper’s Insight Applied

The Earned Autonomy paper establishes that trust is earned through empirical evidence. The trust function requires:

Trust(agent, domain, time_window) = f(
    governance_posture_history,
    verdict_consistency,
    error_rate_trajectory,
    boundary_adherence,
    self-observation_accuracy,
    recovery_behavior,
)

AIGP-Light contributes to four of these six inputs:

Trust Input	AIGP-Light Contribution
`governance_posture_history`	Continuous behavioral metrics over time
`error_rate_trajectory`	Error rate detection with temporal windowing
`boundary_adherence`	Policy enforcement evidence — the system stayed within bounds
`recovery_behavior`	FALLBACK and CIRCUIT_BREAK responses demonstrate governed recovery

The remaining two (verdict_consistency, self-observation_accuracy) require external observers (Receivers) — which is exactly what Level 2+ provides. But the trust accrual begins at Level 1. A system that has been running AIGP-Light for six months arrives at full AIGP with a trust history, not a blank slate.

AIGP-Light is not a toy version of governance. It is the beginning of the evidence stream that eventually demonstrates earned autonomy.

Why This Cannot Be a Separate Protocol

AIGP-Light must be part of the AIGP ecosystem, not a competing standard, because:

Format compatibility is not optional. If AIGP-Light traces used a different format, upgrading would require data migration. Migration is the enemy of adoption. Same format means same evidence, forever.
The trust function is cumulative. Trust earned under AIGP-Light must count toward the autonomy dial. This is only possible if the evidence speaks the same language.
Dialect consumption must be seamless. When an AIGP-Light user subscribes to their first Dialect, the Receiver must be able to consume all historical traces — not just traces produced after upgrade.
The network effect requires inclusivity. If AIGP-Light were a separate protocol, it would fragment the emitter base. Platform economics require one evidence format, one protocol family, one network.
Governance must not punish early adopters. Teams that start with AIGP-Light chose governance over no governance. They should be rewarded — with forward-compatible data, seamless upgrades, and trust that accrues from day one.

Architecture: The Three Components

AIGP-Light consists of exactly three components:

1. Interceptor

The interceptor wraps model calls — the same pattern used by all existing AIGP adapters (OpenAI, Anthropic, LangChain, etc.):

flowchart TD
    subgraph APP["Application Code"]
        A["response = model.chat(messages)"]
    end

    subgraph LIGHT["AIGP-Light"]
        B["Intercept"] --> C["Policy Eval"]
        C --> D{"Breach?"}
        D -->|No| E["Pass Through"]
        D -->|Yes| F["Response Action"]
        F --> G["LOG / ALERT / RATE_LIMIT / FALLBACK / BLOCK / CIRCUIT_BREAK"]
        E --> H["Trace Emit"]
        G --> H
    end

    A --> B
    H --> I["actual_response (or BLOCK/FALLBACK)"]

    style LIGHT fill:#2c3e50,color:#ecf0f1
    style APP fill:#34495e,color:#ecf0f1

The interceptor:

Captures timing (start/end of model call)
Captures token usage from response
Captures success/failure status
Feeds all signals to the policy engine
Does NOT modify the request (unless BLOCK/FALLBACK triggers)

2. Policy Engine (Local)

The policy engine evaluates detection signals against configured thresholds and determines response actions. It is:

Local — no network calls, no external service
Declarative — configured via YAML, not code
Stateful — maintains windowed metrics for temporal thresholds
Deterministic — same signals + same policy = same response

Policy configuration:

version: "1.0"
model_id: "gpt-4o"

detection:
  latency:
    p95_threshold_ms: 3000
    window: 60s
  refusal_rate:
    threshold: 0.15
    window: 300s
  error_rate:
    threshold: 0.05
    window: 60s
  token_explosion:
    multiplier: 3.0
    baseline_window: 3600s
  cost:
    max_per_minute_usd: 1.00

response:
  latency.p95_threshold_ms:
    - LOG
    - ALERT
  refusal_rate.threshold:
    - LOG
    - ALERT
    - RATE_LIMIT
  error_rate.threshold:
    - LOG
    - CIRCUIT_BREAK
  token_explosion.multiplier:
    - LOG
    - FALLBACK
  cost.max_per_minute_usd:
    - RATE_LIMIT
    - ALERT

trace:
  output: file           # file | stdout | callback
  path: ./aigp-traces/
  format: jsonl          # jsonl | ndjson

3. Trace Emitter

The trace emitter produces RFC-010 §5.3 compatible spans. It is a simplified version of the existing TraceBuilder — using only stage 9 (runtime_invocation) for normal calls, and stage 26 (circuit_breaker_evaluation) when a response action fires.

The emitter:

Writes traces locally (no network required)
Supports multiple outputs (file, stdout, callback)
Batches writes for performance
Includes detection metadata as span attributes
Is forward-compatible with full AIGP trace ingestion

The Upgrade Path

timeline
    title AIGP-Light Upgrade Path
    section Day 1
        pip install aigp-light : 5 lines of code : Local policy enforcement : Traces accumulating
    section Month 3
        pip install aigp-agent-core : Switch to AgentGovernance : Traces flow to governance service : Historical traces importable
    section Month 6
        pip install aigp-client : Full protocol — delegation, streaming, anticipation : All prior traces in trust function : Dialect subscriptions consuming evidence
    section Month 12
        Trust posture = 0.87 : Earned autonomy justified : Evidence existed from Day 1

At no point does data migrate. At no point does format change. At no point does historical evidence become unusable. The system evolved — the evidence record is continuous.

The Economic Argument

For the Platform (Causum)

AIGP-Light increases the emitter base — the demand side of the two-sided economy:

More emitters producing traces → more potential Dialect subscribers
Lower barrier → faster adoption → network effects accelerate
Trust accrual begins earlier → Earned Autonomy thesis becomes empirically demonstrable at scale
Teams that start with AIGP-Light are pre-qualified leads for full AIGP

For the Enterprise

Day 1 ROI: Behavioral monitoring with zero infrastructure cost
Risk reduction: Automated response to model degradation
Compliance readiness: When regulators ask “how do you govern your AI?” — you have traces. Not full governance, but evidence that governance exists and is evolving.
No vendor lock-in: AIGP-Light is open-spec. The traces are yours. The policy is yours. Upgrade when ready — to AIGP, or to anything that reads RFC-010 §5.3.

For the Individual Developer

No permission needed. AIGP-Light doesn’t require a governance service, a security review, or organizational buy-in. It’s a pip install and a YAML file.
No performance penalty. Policy evaluation is microseconds (in-process, deterministic). The model call dominates latency.
No operational burden. No services to monitor, no databases to maintain. Traces are files. Policy is YAML.

Why Not Just Use OpenTelemetry?

A reasonable question. The answer has three parts:

OTel traces have no governance semantics. They tell you a call happened. They don’t tell you whether the call should have happened, what policy applies, or what response fired. AIGP-Light traces carry governance context — detection state, policy evaluation, response actions.
OTel has no policy engine. Observability is necessary but insufficient. Knowing your model is slow is useful. Automatically rate-limiting when it’s slow is safety. AIGP-Light is not observability — it is governance that happens to produce observable traces.
OTel is not forward-compatible with AIGP. An OTel span cannot be consumed by an AIGP Dialect. An AIGP-Light span can — because it uses the same format. The upgrade path from OTel to AIGP requires data migration. The upgrade path from AIGP-Light to AIGP requires a pip install.

Conclusion

The AI governance market has a missing rung on the ladder. Below it: ungoverned systems accumulating risk. Above it: comprehensive governance requiring significant investment. The missing rung is not simpler governance — it is the minimum governance that provides immediate safety, produces forward-compatible evidence, and begins the trust accrual that enables earned autonomy.

AIGP-Light is that rung:

Detect behavioral deviation at the model call boundary
Respond with automated policy enforcement
Trace in the format that makes everything above it accessible

It is not a fork of AIGP. It is not a simplification of AIGP. It is the entry point — the first step on a continuous gradient from ungoverned to fully autonomous. And because it produces evidence from day one, every system that uses it is already on the path toward earned autonomy.

The most important governance is the governance that gets adopted. AIGP-Light gets adopted — because it costs nothing, requires nothing, and starts earning trust immediately.

Appendix: Comparison Matrix

Capability	Raw API Call	AIGP-Light	Full AIGP
Model invocation	✓	✓	✓
Latency monitoring	✗	✓	✓
Behavioral detection	✗	✓	✓
Automated response	✗	✓	✓
RFC-010 traces	✗	✓	✓
External service required	✗	✗	✓
Delegation/VLT	✗	✗	✓
Multi-agent governance	✗	✗	✓
Regulatory contexts	✗	✗	✓
Consent management	✗	✗	✓
Streaming governance	✗	✗	✓
Anticipation engine	✗	✗	✓
Dialect subscription	✗	✗	✓
Evidence graph	✗	✗	✓
Trust accrual	✗	✓ (partial)	✓ (full)
Time to integrate	0	5 minutes	Hours–Days
Operational overhead	None	None	Moderate

Artifact	Relationship to AIGP-Light
RFC-010 (Core Protocol)	Trace format that AIGP-Light emits
RFC-010 §5.3 (Trace Spans)	Exact span schema used by trace emitter
`aigp-agent-core`	The Level 2 upgrade target (replaces AIGP-Light interceptor)
Adapters (OpenAI, etc.)	Interceptor pattern that AIGP-Light reuses
`TraceBuilder`	Code that AIGP-Light’s trace emitter is derived from
Earned Autonomy paper	Thesis that AIGP-Light enables from day 1
Not Another Taxi paper	Platform economics that include AIGP-Light emitters
Dialect Registry (RFC-038)	Future consumer of AIGP-Light traces

Position Paper: AIGP-Light — Graduated Governance Through Minimal Detect & Respond

Position Paper: AIGP-Light — Graduated Governance Through Minimal Detect & Respond

Thesis

The Problem: The Governance Adoption Cliff

Full AIGP Is Comprehensive — and That’s the Problem

The Adoption Cliff

The Solution: Graduated Governance

The Governance Spectrum

Why Level 1 Is the Critical On-Ramp

What AIGP-Light Does

Detect

Respond

Trace

What AIGP-Light Does NOT Do

Compatibility with the AIGP Ecosystem

The Taxi Paper’s Insight Applied

The Earned Autonomy Paper’s Insight Applied

Why This Cannot Be a Separate Protocol

Architecture: The Three Components

1. Interceptor

2. Policy Engine (Local)

3. Trace Emitter

The Upgrade Path

The Economic Argument

For the Platform (Causum)

For the Enterprise

For the Individual Developer

Why Not Just Use OpenTelemetry?

Conclusion

Appendix: Comparison Matrix

Appendix: Related AIGP Artifacts