> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spineworkspace.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 10 — Activation Contract

> The activation contract that governs when and how triage becomes active for a tenant.

# 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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.