Context
During casehub-devtown Epic 2 design, a systematic problem was identified: any CaseHub application that uses trust-based routing faces a cold-start problem. On day-1 of a fresh installation, no agent has trust history. Without an explicit maturity model, trust-based routing either blocks all work or is silently bypassed.
devtown defines a four-phase maturity model governed by `RoutingPolicy.minimumObservations`. This pattern is not devtown-specific — it applies to any application built on the CaseHub foundation.
The pattern
Four phases, automatic transitions, no operator intervention:
| Phase |
Name |
Trust data |
Routing mode |
| 0 |
Bootstrap |
None |
Availability — identical to GUPP/Gastown |
| 1 |
Emerging |
Sparse |
Threshold for mature agents, availability for new |
| 2 |
Active |
Sufficient |
Full threshold + borderline uncertainty detection |
| 3 |
Adaptive |
Rich |
Per-capability quality floors (requires CAPABILITY_DIMENSION scores) |
Core principle: the system never fails or blocks because of missing trust data. Phase 0 is availability routing — identical to Gastown's GUPP. Trust routing activates automatically as minimumObservations thresholds are crossed per agent per capability.
Degradation guarantee: every capability has a fallbackType in its RoutingPolicy — what to do when no agent qualifies. Never "do nothing silently."
Phase detection API:
RoutingPolicy.isBootstrap(int agentObservations) // below minimumObservations → availability routing
RoutingPolicy.isBorderline(double trustScore) // within margin → HumanOversight
Why this matters
Without this pattern:
- New deployments appear broken (routing blocks on zero-trust agents)
- Operators manually seed trust scores or disable thresholds
- Each application re-solves the same cold-start problem independently
With this pattern:
- Day-1 experience: Gastown parity (availability routing)
- Week-N experience: trust routing engaging naturally as evidence accumulates
- No configuration changes required at any transition point
Action
Add to docs/PLATFORM.md Step 4 (or a new conventions file docs/conventions/trust-maturity-model.md) under the SPI default implementation rules section.
The canonical implementation is in devtown: RoutingPolicy.java, DevtownCapabilityRegistry.java.
References
- devtown Epic 2 spec:
specs/2026-05-08-epic2-domain-model-design.md (Trust Maturity Model section)
- devtown PROGRESS.md: DT-006
- ledger#76: CAPABILITY_DIMENSION composite scores (Phase 3 dependency)
The edit to PLATFORM.md will be made in the parent session once this issue is reviewed.
Context
During casehub-devtown Epic 2 design, a systematic problem was identified: any CaseHub application that uses trust-based routing faces a cold-start problem. On day-1 of a fresh installation, no agent has trust history. Without an explicit maturity model, trust-based routing either blocks all work or is silently bypassed.
devtown defines a four-phase maturity model governed by `RoutingPolicy.minimumObservations`. This pattern is not devtown-specific — it applies to any application built on the CaseHub foundation.
The pattern
Four phases, automatic transitions, no operator intervention:
Core principle: the system never fails or blocks because of missing trust data. Phase 0 is availability routing — identical to Gastown's GUPP. Trust routing activates automatically as
minimumObservationsthresholds are crossed per agent per capability.Degradation guarantee: every capability has a
fallbackTypein itsRoutingPolicy— what to do when no agent qualifies. Never "do nothing silently."Phase detection API:
Why this matters
Without this pattern:
With this pattern:
Action
Add to
docs/PLATFORM.mdStep 4 (or a new conventions filedocs/conventions/trust-maturity-model.md) under the SPI default implementation rules section.The canonical implementation is in devtown:
RoutingPolicy.java,DevtownCapabilityRegistry.java.References
specs/2026-05-08-epic2-domain-model-design.md(Trust Maturity Model section)The edit to PLATFORM.md will be made in the parent session once this issue is reviewed.