Decision Return Diagnostic

Your team can do the work. The decision still returns to you.

A task has been delegated. The team begins the work. Then an exception appears, the available evidence becomes unclear, or someone has to decide what the standard requires.

The work returns to the founder.

The Decision Return Diagnostic identifies why that return keeps happening and designs one bounded decision loop the company can test safely in shadow mode.

We examine the standards, context, evidence, precedents, exceptions, and authority behind the decision. Then we translate the repeatable portion into clear decision rights, preparation requirements, escalation conditions, and a working operating design.

The purpose is not to remove the founder from every consequential decision. It is to stop routing decisions back to the founder when the company should already know how to prepare, decide, or escalate them.

What you receive

1. Decision Return Map

A clear account of where the selected decision begins, why it returns, who touches it, what pauses while the team waits, and where authority is currently unclear.

2. Founder-Touch Baseline

A before-state record using the evidence available for the selected loop: founder touches, returned decisions, waiting time, overrides, revisions, rework, escalation, and relevant economic consequences.

3. Judgment Record

The standards and context behind the decision, recovered from real approved, rejected, corrected, and exceptional cases—not inferred from a generic best-practice template.

4. Decision Rights and Escalation Matrix

A precise definition of:

• what the team may decide;
• what the team may prepare;
• what evidence is required;
• what may proceed within established boundaries;
• what must escalate;
• who retains authority;
• what should not be delegated.

5. Shadow-Mode Decision Loop

One bounded operating design that can be tested beside live work before authority changes. The loop may include an intake, evidence packet, decision brief, quality check, exception path, escalation step, and outcome record.

6. Measurement Plan

A defined method for determining whether routine founder involvement decreases without increasing overrides, rework, client escalation, missed exceptions, unauthorized commitments, or margin loss.

What shadow mode means

The new loop prepares or recommends. The authorized human still makes the live decision.

The recommendation is compared with the actual decision, the evidence used, the reason for any disagreement, and the downstream outcome. Only decision lanes that demonstrate reliable reasoning and correct escalation should later receive greater operating authority.

No client or customer communication is automated through this pilot. No system receives authority merely because it can perform the task.

A strong first loop

The selected loop must be:

• recurring enough to observe;
• consequential enough to matter;
• bounded enough to isolate;
• supported by real prior examples;
• safe enough to test in shadow mode;
• capable of having its quality defined;
• owned by a real internal role after design;
• reversible if it performs poorly.

Possible loops include recurring scope questions, approval preparation, project-fit qualification, change-request triage, proposal readiness, internal review readiness, or another decision the company repeatedly returns to the founder.

The client’s actual burden determines the loop. UNTETHERED does not impose a generic automation use case.

What this engagement does not include

• a whole-company operating-system installation;
• autonomous client communication;
• legal advice or contractual interpretation;
• transfer of licensed, fiduciary, life-safety, or otherwise regulated judgment;
• automatic authority to waive fees, alter timelines, approve additional work, or make commitments;
• replacement of the founder’s strategic, creative, ethical, or relationship authority;
• a production automation build;
• a promise that every form of judgment can be reduced to a rule.

AI’s role

AI may help retrieve approved precedent, organize evidence, check completeness, draft a decision brief, or flag an exception where the boundary is explicit.

AI does not inherit authority merely because it can perform the task.

The system prepares. The appropriate human decides.

Ownership

The client owns the standards, working records, decision history, configurations, and operating intelligence created through the engagement.

UNTETHERED does not make the company dependent on a closed system in order to preserve the judgment it helped uncover.

The proof standard

A successful engagement must show both:

Reduced founder dependence

Fewer unnecessary founder touches, fewer decisions returning, less waiting, and less repeated explanation inside the selected loop.

Preserved quality and authority

No unacceptable increase in overrides, rework, client escalation, missed exceptions, unauthorized decisions, or economic loss—and correct escalation of the decisions that still require human authority.

Reducing founder involvement while lowering the standard is not success.

Your company should carry your judgment—not consume your attention.

Begin with one decision it should no longer need you to carry personally.

---

Purchase boundary: Purchase reserves one fixed-scope pilot engagement. The selected decision loop and evidence access are confirmed before substantive work begins. Work outside the bounded diagnostic and shadow-mode loop design requires a separate written scope.