# Synthetic Sample Mission — Improve a Fictional Clinic Callback Workflow

> **Fixture only.** Every person, site, number and outcome below is invented for build and test use. This is not a benchmark, recommendation, clinical workflow, institutional approval or record of a completed real action. It contains no PHI or personnel information and must never be presented as evidence of user achievement.

## Mission header

| Field | Synthetic value |
|---|---|
| Starter seed key | `starter-synthetic-access-001` |
| Mission ID | `6bd10b61-ec30-4f9f-9c2c-dcfdb1387ac6` |
| Workspace | Fictional clinic administration |
| Active hat | Administrative |
| Owner | Synthetic test owner |
| Status | Starter content — not adopted |
| STEWARD pillar | T — Transform access, flow and operations |
| Suggested power | `PWR-05` — Access, Demand & Capacity Intelligence Studio — Available Inactive |
| Suggested workflow/template | `WF-05` — Access, Demand, Capacity & Equity Brief / `TPL-09` — Access, Demand, Capacity & Equity Brief |
| EDENA | Yellow — operational recommendation requires deliberate human review |
| CHART | `Pass` for local synthetic preparation only; it grants no operational authority |
| Data class | Synthetic aggregate fixture only |
| External execution | Prohibited |

### CHART findings for this fixture

- **C — Context, constituency and consequence:** local build-test fixture; no real entity, patient, employee or community member; intended outcome is state-machine verification.
- **H — Human authority and accountable owner:** the local test owner may create, edit, approve and run this synthetic fixture only; operational authority is explicitly absent.
- **A — Authorization, access, agreements and approved action:** generated records, local test database and local simulation only; no connector, official system or external destination.
- **R — Regulation, risk, resources and records:** no regulatory or operational conclusion; preserve synthetic label, version, assumptions and test receipt.
- **T — Trace, test, transition, expiry and termination:** exercise every maturity gate, Pause, rollback, review, fixture reset and deletion with a receipt.

## Mission statement

Explore whether a fictional clinic could shorten its aggregate callback interval without increasing unsafe workload, missed escalation or inequitable access. Produce a human-reviewable experiment plan; do not alter a real schedule, queue, staffing assignment or patient process.

## Success measures

- Synthetic median callback interval changes from four business days to two or fewer during an eight-week simulation.
- Synthetic high-priority messages retain the fictional same-day escalation rule.
- Synthetic rework does not rise above 8% of simulated messages.
- The fictional team reports no increase in simulated overtime above the stated stop threshold.
- Every proposed real-world action remains blocked until the actual accountable owner, policy, baseline and institution-approved data path are verified.

## Stage 1 — Assess

**Artifact state:** Exploration

### Verified facts

None. This fixture contains no real organization facts.

### User-provided information

None. All content is synthetic.

### Synthetic observations for the test

- 240 fictional callback requests arrive per week.
- The simulated median interval is four business days.
- Requests enter through three fictional channels with inconsistent labels.
- One fictional escalation rule requires same-day human review for a defined high-priority category.
- The simulated team can test one small workflow change for eight weeks but cannot add staff.

### Assumptions

- Duplicate intake and unclear ownership may contribute to delay.
- A shared triage label may reduce rework.
- Aggregate workload measures may hide distributional burden.

### Unresolved questions

- What is the real approved service promise, if any?
- Who owns clinical triage, operations, privacy, workforce and final implementation decisions?
- Which official system is authoritative?
- What approved aggregate data can be used, and under what retention policy?
- Which access or equity strata may be reviewed without re-identification risk?

### Assess checkpoint

The local test owner may advance this synthetic fixture to Define under the synthetic-only CHART Pass. The system must not describe the observations as verified facts or retrieve/process real data.

## Stage 2 — Define / Diagnose

**Artifact state:** Simulation

### Bounded problem statement

In the synthetic test environment, inconsistent intake labels and unclear queue ownership are associated with a four-business-day median callback interval. The build must treat this as a test hypothesis, not a causal conclusion.

### Competing interpretations

1. Intake duplication is the principal constraint.
2. Handoff ambiguity, not intake volume, is the principal constraint.
3. The median obscures a smaller high-delay subgroup.
4. The fictional capacity assumption is wrong.

### Dependencies and risks

- a named human owner and a verified authority source;
- an approved operational definition and official data source;
- workforce review of load and psychological-safety effects;
- clinical review of escalation boundaries;
- privacy/equity review before subgroup analysis; and
- a stop rule if high-priority handling, rework or workload worsens.

### Define checkpoint

Store the interpretations, uncertainty and dependency graph. Do not automatically select a diagnosis or activate an agent.

## Stage 3 — Plan

**Artifact state:** Draft artifact

### Options compared

| Option | Expected benefit | Cost/time | Principal risk | Test disposition |
|---|---|---|---|---|
| A. Keep the synthetic workflow unchanged | Provides a comparison state | Low | Delay continues | Retain as comparator |
| B. Add one shared intake label and named daily queue owner | May reduce duplicate review and ambiguity | Moderate, two-week setup | Load concentration or missed nuance | Preferred synthetic experiment |
| C. Add a new automated routing agent | Could accelerate sorting | High | Incorrect routing, hidden bias, expanded data exposure | Not authorized; exclude from first experiment |
| D. Add staffing | Could increase capacity | High | No fictional budget/authority | Out of scope |

### Selected synthetic plan

- Simulate Option B for eight fictional weeks.
- Use only generated aggregate records.
- Define the callback interval, rework rate, high-priority escalation rate and workload signal before the run.
- Review weekly; pause on any missed high-priority escalation or on workload above the synthetic threshold.
- Keep the original synthetic workflow available for rollback.
- Create a decision brief labeled `Simulation — not approved for operational use`.

### Required human gates before any real use

- administrator owner confirms scope and authority;
- clinical owner validates escalation logic;
- workforce owner reviews load and role design;
- privacy/security owner approves the data path;
- quality/equity owner approves definitions and stratification; and
- the institution records authorization in its official system.

### Required maturity transitions for the fixture

1. **Recommendation:** Option B is recommended for a local synthetic experiment only.
2. **Draft artifact:** the experiment plan and decision brief are saved as editable drafts.
3. **Approved plan:** the local test owner approves only the generated-data test plan and its limits; real operational approval remains false.
4. **Authorized execution:** a second deliberate confirmation authorizes one local synthetic run, with no model, connector or external action.

Every transition receives its own timestamped test receipt. Skipping or combining a gate must fail.

### Plan checkpoint

The preferred option remains a sandbox recommendation for any real setting. `Approved plan` and `Authorized execution` may become true only for the bounded synthetic fixture after the two distinct confirmations above; both remain false for real-world use.

## Stage 4 — Implement

**Artifact transition:** Authorized Execution → Completed Action — synthetic simulation only

### Concrete fixture tasks

1. Generate 240 nonidentifiable fictional requests for each simulated week.
2. Apply the shared fictional intake label.
3. Assign a synthetic daily queue-owner role; never assign a real employee.
4. Run the simulation and record the four predefined aggregate measures.
5. Trigger the pause path in one test run and verify rollback.
6. Produce a draft experiment brief and a governance receipt.

### Authorized execution record

Authorization covers only local synthetic test execution. It grants no permission to change a clinical or operational system, contact a person, schedule work, publish results or use protected/restricted data. All SuperPowers and agents remain Inactive/Disabled unless a separate bounded test explicitly authorizes one.

### Implementation result for the fixture

The synthetic runner completes, the pause control stops the simulated run, and no external call is made. Hermes must replace this sentence with observed test evidence when implementing the application; prose in this file is not proof that the behavior passed.

## Stage 5 — Evaluate

**Artifact state:** Evaluated synthetic outcome

### Illustrative generated result

- Median synthetic callback interval: 2.3 business days.
- Synthetic high-priority escalation: 100% within the fictional rule.
- Synthetic rework: 7%.
- Synthetic workload stop threshold: not crossed.

These generated values do not show that the option will work in a real clinic.

### Evaluation

- The two-day target was not met; the simulation suggests a possible improvement worth a narrower second test.
- High-priority and rework safeguards passed only within the generated fixture.
- Causality, feasibility, equity, staff experience and real-world safety remain unresolved.
- The correct disposition is **Revise and iterate**, not operational adoption.

### Next Assess stage

Begin iteration two by testing whether handoff timing, rather than intake labels, explains the remaining synthetic delay. Preserve iteration one, its assumptions, generated inputs, version and governance receipt.

## Required application behaviors demonstrated by this fixture

Hermes should turn this narrative into a versioned Starter fixture and automated tests proving that:

- Starter content is clearly labeled, removable, restorable and excluded from achievements;
- fact, user input, synthetic observation, assumption and unresolved question remain distinct;
- each stage has a review checkpoint and can be paused or revised;
- a sandbox recommendation is not displayed as an approved operational plan;
- only the synthetic local task receives execution authorization;
- external execution, restricted data and agent activation remain blocked;
- Evaluate can create a linked new iteration without rewriting the old one; and
- changing a material Assess value reopens downstream review and clears stale approval.
