BMT-04.02 Executive Summary#
BlueMirror.tech | May 2026#
Rajesh has built AI recommendation systems for six years and knows the failure mode: the system starts conservative, gets ignored, the product team bumps up the default, and the system starts acting on insufficient knowledge. Confirmation prompts follow, then fatigue, then theater. The pattern repeats because autonomy is set as a static configuration. The answer is not a better default. It is a different structure.
Autonomy should be earned through demonstrated competence. Not assumed at onboarding. Not purchased by the subscription tier. Earned through a record of correct decisions across a range of real situations, with the person’s explicit agreement at each step up. Competence is measured by the actual range of scenarios encountered, not just common ones. A system that has only been tested in normal conditions has not been tested.
The evidence package that supports each level transition rests on five signals. Accuracy measured by the person’s subsequent behavior, not the model’s confidence score. Escalation appropriateness: did the system ask when it should have and act when it should have? Error recovery: did the system catch mistakes, correct them, and adjust? Edge case handling: did the system recognize unusual situations and escalate appropriately? Person satisfaction measured through behavioral signals rather than surveys.
Five progression levels structure the earning. Observe (Level 1) is thirty days of watching and learning. Recommend (Level 2) is explicit recommendations with approval. Act and Notify (Level 3) requires twenty correct recommendations with no major errors. Act and Report (Level 4) requires fifty correct autonomous actions with demonstrated appropriate escalation. Full Delegation (Level 5) requires one hundred correct actions and is never available for healthcare clinical decisions. Each transition is proposed by the system and decided by the person.
Autonomy moves in both directions. The person who starts managing her own medication schedule after the system handled it for a year is not treated as a problem. The system provides the schedule in her preferred format, monitors adherence without nagging, and offers to resume if asked. The system’s job is to serve the person, not to be needed by the person.
Dependency detection monitors the system’s own indispensability across three warning signals: no manual engagement in ninety days, the system handles everything with no person-initiated action, and the pattern persists without variation. The response is not withdrawal of service but a low-friction invitation to stay connected. The invitation is offered once per cycle. The person who wants the system to handle everything has that option.
Cross-domain earning transfer, where competence in one domain provides a partial starting base in an adjacent domain, is twelve months out. The architecture supports the transfer. The safety analysis for calibrating how much to weight prior domain competence without creating an incorrect sense of earned autonomy is still in progress.
The full article is available at bluemirror.tech.