10 — Activation Contract

Triage is considered active only when ALL of the following conditions are true:

10 Activation Requirements

1. Triage Runtime Deployed

The TriageAgent Durable Object in iw-agent-runtime is deployed and healthy.

Verification: GET /health on iw-agent-runtime returns triage agent status.

2. Intake Trigger Wired to Flow C Ingress

The intake trigger is connected to the intended Flow C ingress point:

• MCP Connector → /v1/triage/session
• Conversation Archive → /conversations/:id/archive → triage-bot
• Runtime TriageAgent → triage() → emitTriageInput()

Verification: An incoming event from any source reaches the triage boundary.

3. Staging Writes Are Tenant-Scoped

All triage writes are scoped to the tenant that produced the evidence:

• triage_items has tenant_id
• triage_results.metadata contains tenant_id
• No cross-tenant data leakage

Verification: Query triage_results filtered by metadata->>'tenant_id' returns only that tenant's items.

4. Approval Endpoint Updates Review State

The PATCH /v1/knowledge/triage/:id endpoint correctly updates approval_status:

• pending → approved (triggers consolidation)
• pending → discarded (terminal)
• pending → deferred (resumable)

Verification: PATCH with action: "approve" changes status to approved and records approved_by and approved_at.

5. Approval Triggers Canonical Promotion

When a triage item is approved:

1. Status changes to approved
2. Consolidation queue is triggered (if TASKS_QUEUE available)
3. Memory Consolidator picks up approved items
4. Pipeline promotion engine writes to org_memory

Verification: Approve a triage item → wait for consolidation → verify org_memory row exists with governance_state = 'approved'.

6. Direct Canonical Writes from Triage Are Impossible

Triage runtime credentials and bindings cannot write to:

• org_memory directly
• Canonical Neon tables
• R2 as canonical storage
• Vectorize as truth source

Verification: Attempt to call Pipeline memory-write from triage context → should fail or be rejected.

7. Rejection/Defer/Repair Are Terminal or Resumable

Action	State	Audit
reject	terminal	Full audit trail
defer	resumable	Returns to pending on re-trigger
repair	resumable	Fix and re-triage

Verification: Reject an item → verify no org_memory row. Defer → verify it returns to inbox.

8. Approved Memory Appears in Canonical Retrieval

After promotion:

• Approved memory is in org_memory with governance_state = 'approved'
• AI Search index contains the memory
• Twin can retrieve it through bounded context projection

Verification: Approve → promote → search for the memory → verify it's retrievable.

9. Rejected Memory Does Not Appear

After rejection:

• No org_memory row
• No AI Search index entry
• No Twin context projection

Verification: Reject an item → search for it → verify it's not found.

10. End-to-End Path Proven in Customer Zero

The complete path is proven in Customer Zero before external tenants:

• Intake → Triage → Staging → Governance → Promotion → Indexing → Consumption
• All 10 requirements verified in production-like environment

Observability Requirements

When active, triage must expose:

• Throughput — items/minute processed
• Pending queue — items awaiting review
• Approval latency — time from staging to decision
• Promotion success — items successfully promoted
• Promotion failure — items that failed promotion
• Rejection rate — percentage of items rejected