Skip to main content

​
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

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