Architecture: How should adaptive trust scoring work — static per-role vs ...

Documentation for Sessions

🏗️ Architecture: How should adaptive trust scoring work — static per-role vs ...

Date: 2026-03-20
Time: 17:40:16 UTC
Session: gspace1-240.4
Agent: backend
Confidence: 92%
Status: ✅ Documented

📋 Decision Context

Question:

How should adaptive trust scoring work — static per-role vs dynamic per-user-per-domain?

Task: S240: Adaptive trust scoring system

🎯 Decision Made

Chosen:

Dynamic trust scoring per (userId, actionDomain) pair. Score 0-100 computed from last 50 outcomes weighted by complexity and recency. Maps to OBSERVE/SUGGEST/DIRECT/AUTONOMOUS. Escalation capped at one level per week, but drops immediately on critical failures. Materialized in MongoDB, updated event-driven after each outcome.

Options Considered:

Static per-role trust (current — developer always DIRECT)
Dynamic per-user global score (one score for everything)
Dynamic per-user-per-domain scores (chosen — granular trust)

💭 Reasoning

Static per-role trust (developer=DIRECT, user=SUGGEST) ignores proven reliability. A user who has 50 successful code executions should earn higher trust than a new developer with 0 history. Domain scoping is critical: trust for 'search docs' (low risk) should not equal trust for 'run_command' (high risk). Asymmetric escalation/drop mirrors human trust dynamics — earned slowly, lost quickly. Materialized scores avoid computing from 50 outcomes on every gate evaluation (~50ms saved per call). The existing OutcomeFeedbackService already collects the data; TrustScoringService just needs to consume it.

📁 Files Involved

APIs/backend-vitto-api/src/app/engine/trust-scoring.service.ts
APIs/backend-vitto-api/src/app/engine/schemas/trust-score.schema.ts

🔗 Related

Decision ID: dev_1774028416516_z4mge7c
Session: 240
Workspace: gspace1

Auto-generated by MCP Smart Consolidation