07 — Governance Boundary

What Triage May Write

Triage may write only to bounded operational/staging state:

Write	Table/Store	Purpose
Triage item	triage_items (DO SQLite)	Operational intake record
Extracted candidate	triage_results (Neon/D1)	Staging for human review
Classification	triage_results.classification	Category, type, intent
Entity links	triage_results.metadata.entity_refs	Links to known entities
Provenance	triage_results.metadata	Source, tenant, user
Confidence	triage_results.confidence	Quality dimensions
Conflict findings	triage_results.metadata.canonical_review	Duplicates, conflicts
Review state	triage_results.approval_status	pending/approved/discarded/deferred
Continuity event	Continuity service	Evidence emission

These writes are operational records, not canonical organizational truth.

What Triage May Never Write

Triage must never directly write:

Forbidden Write	Why
Canonical entity state	Only governed canonical writers
Approved organizational memory	Only Pipeline promotion
Authoritative policy	Only Governance service
Permissions	Only Identity service
Authority grants	Only Governance service
Canonical relationships	Only Pipeline/Spine
Promoted outcomes	Only Pipeline promotion

The Authority Law

Confidence never grants authority.

A 0.99-confidence proposal and a 0.55-confidence proposal require the identical approval to become real. Confidence describes evidence quality. It is an input to human judgement, never a substitute for it.

Human Decision Boundary

The PATCH /v1/knowledge/triage/:id endpoint is the human decision boundary. It requires:

1. Authenticated principal — x-user-id header
2. Tenant authority — x-tenant-id header, must match triage item
3. Optimistic check — current state must be pending or deferred
4. Approver identity/time — recorded in metadata
5. Immutable audit — decision logged with full context
6. Promotion event — on approve, triggers consolidation queue

The endpoint itself does not become a second canonical writer. It updates review state and triggers downstream processes.

Slack as Review Channel

Slack is a review channel, not an authority bypass. A Slack reaction must become a verified approval event:

1. Reaction received → verify binding to triage item
2. Verify tenant and principal identity
3. Verify candidate version hasn't changed
4. Create approval event with full audit context
5. Route to consolidation pipeline

The Slack integration never writes canonical memory directly.