AI product briefs grounded in user needs and accountability

Learn in your browser · Chapter 01 of 08

Turn a requested feature into a task hypothesis that alternatives and actual research can challenge.

Tern-Adult-Enquiry-Training begins with a familiar design request: add an AI chat assistant. The request tells the team what a sponsor imagines, but it does not tell them what an adult needs to accomplish. Tern is an invented service team examining preparation of a general tenant enquiry. Its purpose is design-brief-teaching. No enquiry reaches a landlord, no actual participant is involved and no housing decision is made. The first design task is to locate the problem hidden inside the requested feature, while keeping the sponsor's preference available for challenge rather than silently accepting it as evidence.

A problem statement connects a person, a task, a context and an obstacle. A need statement describes the outcome the person wants. A solution describes one way the service might help. These statements belong together, but they are not interchangeable. Someone may need to know what information to include without needing a conversation with software. They may need to correct an enquiry before handoff without needing a predictive answer. When a proposed need says I need an AI chatbot, the technology has already displaced the question the design team should investigate.

T-E01 is a synthetic observation card about a pause at an unexplained description field. The card suggests that the label might be an obstacle. It does not establish why any real person stopped, how common the problem is or whether a new label would solve it. A useful hypothesis is: an adult preparing an enquiry needs to understand the requested information so they can decide what to include. Add the evidence identifier and its kind. That wording permits a clearer label, structured prompts, human help or an AI concept to be compared without making any of them inevitable.

T-E02 is another synthetic observation: a preview enables correction of an omitted detail in an authored vignette. It supports a question about control before handoff. T-E03 is the fictional sponsor's assumption that every tenant prefers chat. The third card cannot turn the first two into a preference study. Keep the proposed task separate from the proposed channel. The Tern brief should ask whether people can identify requested information, correct a draft and reach assistance, rather than treating conversational style as a substitute for those outcomes.

Scroll sideways to see every column.

An outcome also needs a boundary. In Tern, preparing an enquiry is different from receiving an entitlement decision, a repair commitment or advice about a tenancy. A design team can make an input easier to understand while leaving the underlying decision with the relevant service and qualified people. The brief should explain what a successful preparation task would look like and what it does not establish. This avoids a misleading leap from a well-written enquiry to an assured outcome. No actual entitlement, deadline, urgency classification or legal interpretation belongs in this teaching task.

The average brief says: tenants need chat because modern services use AI; success means more conversations. Its evidence is fashion and its measure is activity. The elite brief says: investigate whether adults can identify the limited information requested and correct it before seeking human help. T-E01 and T-E02 are synthetic prompts for that investigation; T-E03 is a competing stakeholder assumption. Compare the structured form and AI concept against the same task, and retain the human route. This brief makes it possible to choose a less elaborate design if that better addresses the problem.

A useful method starts by rewriting the sponsor's sentence without a technology noun. Then identify the exact task, distinguish the hypothesised obstacle from the desired outcome and attach evidence with its kind. Next write an observation that could challenge the hypothesis. For example, future research might find that people understand the description field but hesitate because they distrust where the information goes. A clearer label would then address the wrong obstacle. Finally identify alternatives and exclusions. The brief becomes a set of questions and choices that research can change, rather than a defence of a purchase already imagined.

Be precise about the population and context without creating a fictional persona that pretends to represent it. Adult tenant is a teaching role, not a claim that all tenants share reading, hearing, language or digital needs. A person may use a keyboard, avoid a voice call, need simpler text or lack reliable internet. These are potential journey requirements to investigate. Do not attach an ability label to a fictional person and then claim to know how they behave. The initial brief should show where participation and service access remain unknown.

In the analytical contract, draft_need_hypothesis accepts a nonempty list of known evidence IDs, a known task and the current integer fixture version. On paper, T-E03 alone produces HOLD_ASSUMPTION_ONLY. A supported combination can produce NEED_HYPOTHESIS, which still means a hypothesis. The method preserves card kinds; it cannot convert a synthetic observation into an actual user finding. Duplicate IDs, unknown IDs and boolean versions are invalid. These argument checks make the teaching record inspectable, but they do not evaluate the truth of arbitrary prose or validate a real need.

A team should also know what its proposed measure omits. Counting enquiry starts would not show whether people understood the form, corrected mistakes or reached a human. Counting successful scripted checks would not show actual user success. Define each measure in words, identify its evidence unit and keep the unresolved research alongside it. Early design measures should inform learning, not reward an alternative simply because its interface produces more events. A quieter form that helps someone complete the task may be preferable to a lively conversation that leaves the enquiry unchanged.

The source gds-user-needs supports starting with user goals and testing assumptions; it is government service-design guidance, not a rule automatically binding every private tenant service. gov-ai-playbook supports choosing a suitable technology and allows established alternatives to be better. Neither source validates Tern's cards or authorises a pilot. Use the scoped principles to shape the brief, then record the real evidence and local review that would be needed. A recognised source title is not another stakeholder vote for the desired feature.

The elite handover is short enough to read but complete enough to challenge. It contains a need hypothesis, evidence kinds, task boundary, alternatives, an observable question and missing participation evidence. Its recipient can explain why AI remains an option and why it has not been selected. If the sponsor changes the requested purpose from enquiry preparation to deciding requests, the brief must be reconsidered. That is a different consequential task, not a harmless extension of the same screen. Good problem framing leaves the design decision open while making the limits concrete.

1. Remove the proposed technology from the first problem sentence.
2. Identify the adult task, context, obstacle and desired outcome.
3. Attach exact evidence IDs and preserve their kinds.
4. Write a question that could disprove the obstacle hypothesis.
5. Compare possible designs and retain the human route.
6. Record exclusions, absent evidence and what would trigger reframing.

ROLE: Adult Tern brief drafter.
CONSTRAINTS: Tern-Adult-Enquiry-Training; design-brief-teaching; synthetic evidence only; no housing decision, personal data or pilot.
PROCESS: Separate sponsor request, task, obstacle, need hypothesis and alternatives.
VERIFICATION: Preserve T-E01/T-E02 synthetic kinds and T-E03 stakeholder assumption; check task and current integer fixture version.
OUTPUT SCHEMA: taskId; needHypothesis; evidenceIds; evidenceKinds; challengeQuestion; alternatives; exclusions; missingResearch.
FAILURE MODES: Do not promote chat preference into research, count conversations as task success or call NEED_HYPOTHESIS validated. This is a paper drafting pattern, not a model run.

Text equivalent: start with the sponsor request, identify the task and label the evidence. Combine them into a need hypothesis, keeping it unvalidated. Compare possible designs and retain actual-user and context gaps alongside the choices.

Scroll sideways to see every column.

Learn in your browser · Chapter 02 of 08

Preserve provenance and interpretations, then make absent journeys and unfinished research visible.

An evidence wall can look convincing long before it contains dependable evidence. Cards, quotations, coloured dots and a polished persona invite readers to assume that someone has listened to users. Tern deliberately interrupts that impression. Its six cards are authored teaching materials with different kinds. Their purpose is to help adult designers reason about a brief, not to simulate a completed study. A careful reader asks where a statement came from, what was actually observed, how it was interpreted and whose perspective is missing before using it to choose a design.

An observation records something seen or heard in a defined setting. An interpretation explains what it might mean. An assumption proposes something without that observation. A probe result concerns the criterion exercised by a particular test. These distinctions survive even when the sentences are equally clear. T-E01 and T-E02 are synthetic_observation cards, so they describe authored vignettes rather than actual sessions. T-E03 is a stakeholder_assumption. T-E04 is a synthetic_access_gap. T-E05 is a scripted_probe_set, and T-E06 is a research_gap_register. Keep these exact kinds visible in any summary.

There are two separate questions about each card: what kind of material is it, and how far can it support this decision? T-E01 can illustrate a possible problem with a description label, but it cannot establish that real tenants misunderstand it. T-E05 can support arithmetic about eight authored probe records, but it cannot establish that eight participants completed a task. A known identifier establishes that the card belongs to the fixture. It does not establish external truth, representativeness or the appropriateness of using it in a real service decision.

Scroll sideways to see every column.

The easiest failure is interpretation laundering. A designer reads the synthetic pause at the field and writes tenants cannot complete forms. A colleague then shortens that to users need chat. The sequence loses the original kind, invents a population claim and prescribes an alternative. None of those changes requires a new study; they can happen during editing. Preserve a small evidence chain: card statement, interpretation, proposed need and open question. If the interpretation is broader than the statement, show the difference explicitly instead of hiding it inside a confident summary.

The average evidence summary claims tenants prefer AI and need immediate answers. Its source is T-E03 and its supporting visual is an invented persona. The elite summary says T-E03 records the sponsor's assumption about chat preference; the fixture contains no actual preference research. T-E01 and T-E02 illustrate label and correction questions. T-E04 exposes a human-route gap. T-E05 contains scripted criterion checks. T-E06 lists unfinished research and governance work. The elite summary can still guide a useful next step because it describes exactly what needs investigation rather than manufacturing certainty.

A research question should create a genuine opportunity to discover that the team's explanation is wrong. Do adults understand the requested information and where it will go is more useful than do you like our chatbot. The first question allows label, trust, privacy and process problems to emerge. The second steers attention to a chosen interface. Choose a research method for the question and the people affected. A future observation of task preparation, followed by questions about hesitation, would address a different issue from a survey of channel preferences. Do not claim either has occurred in Tern.

Absent users matter because an easy recruitment route can conceal difficult service journeys. People who can join a video call may differ from people without reliable internet, people who need nonvoice contact or people who use their own assistive technology. A design review should ask who could not participate and what practical arrangements would enable them to do so. It should not invent a diagnosis or treat a language, reading or hearing requirement as a complete personality. Describe the journey requirement and how you would ask about it respectfully.

The fictional human-route gap illustrates why evidence and operation meet. A transcript may display contact by text, but there is no verified text service behind it. Research could show a preference for nonvoice contact while the support team lacks a working process to receive it. That would be a service capability question as well as a design question. Record both. A future research plan needs a support owner and an account of capacity, availability, privacy and follow-through; listing a channel does not prove that an enquiry can reach a person through it.

Use six steps to audit an evidence set. Preserve the original statement and kind. Separate your interpretation from it. Identify the specific decision it could inform. State the limits of that support. List affected people and journeys absent from the material. Finally convert the gaps into research areas and accountable questions. A table is useful because reviewers can compare the statement and interpretation directly. It is also useful in an ordinary text copy, where the reader should not need colours, a wall layout or a persona illustration to understand provenance.

The contract's research-plan method accepts seven exact area IDs: participants, nonvoice-support, assistive-technology, language, privacy, supplier and support-capacity. On paper, record_research_plan with all seven unique areas and the current integer fixture version returns RESEARCH_PLAN_DRAFT. Missing areas predict HOLD_INCOMPLETE_RESEARCH_PLAN. A complete plan increments plan_sequence and invalidates a prior recommendation. This checks whether the teaching plan covers the required headings. It does not recruit anyone, secure consent, resolve supplier processing conditions or validate access. Every factual acceptance flag remains false.

The source gds-research-planning supports turning assumptions into questions and choosing suitable participants and methods. Its supporting disability-session guide asks teams to consider individual requirements and participants' own assistive technology. This is scoped government guidance, not proof that a chosen number of fictional cards is representative. inclusive-accessibility supports attention to online and offline access. assisted-digital-support explains that assistance depends on researched needs; a phone route cannot be presumed usable by everyone. Actual arrangements must be investigated, not inferred from these source titles.

A disciplined evidence handover contains a useful disagreement. A reviewer should be able to say the label hypothesis is reasonable but untested, the channel preference is unsupported, or the nonvoice route remains missing. That disagreement helps the design team plan learning. It is not a failure of presentation. Before any real work, local research governance and privacy review would need to address participation, necessary information, consent and handling. Tern makes no such selections. Its achievement is a transparent plan in which the missing study remains missing, even after every teaching field has been completed.

1. Retain the card statement and exact evidence kind.
2. Write interpretation separately from the statement.
3. Identify the bounded design decision it might inform.
4. State what the material cannot establish.
5. Identify absent people, journeys and operational capabilities.
6. Turn gaps into research areas and questions that can change the brief.

ROLE: Adult Tern evidence editor.
CONSTRAINTS: Six fictional cards; preserve all exact kinds; no participant, diagnosis, research completion or supplier permission claim.
PROCESS: Build statement-to-interpretation rows, identify absent journeys and prepare seven research areas.
VERIFICATION: Check card IDs, distinct original/interpretation wording, participants/nonvoice-support/assistive-technology/language/privacy/supplier/support-capacity and current integer version.
OUTPUT SCHEMA: cardId; kind; statement; interpretation; decisionSupported; limitation; absentJourney; researchQuestion; requiredArea.
FAILURE MODES: Reject assumption-as-observation, synthetic-as-actual, invented personas-as-validation and plan completeness-as-completed research. This paper pattern does not evaluate free-text truth.

Text equivalent: preserve the kinds of six evidence cards, then put each original statement beside its interpretation. Identify limits and absent journeys. A seven-area plan can become a teaching draft; a missing area remains held. Neither branch establishes actual research or successful access.

Scroll sideways to see every column.

Learn in your browser · Chapter 03 of 08

Compare both alternatives fairly while keeping failed tasks, evidence units and shared stops visible.

A fair design comparison asks two alternatives to help with the same task under the same constraints. It does not ask a modest form to prove usefulness while allowing an AI concept to promise everything a future supplier might build. Tern compares structured-form and ai-concept as fixed authored scripts for enquiry preparation. They have four paired task criteria and the same unresolved human-route requirement. The comparison concerns these teaching scripts, not the general merits of all forms or all AI. That narrow scope makes the differences inspectable without pretending a model or participant study has occurred.

Begin with the unit of comparison. T-P01 concerns identifying requested information. T-P02 concerns correction before handoff. T-P03 concerns reaching a nonvoice human route. T-P04 concerns avoiding unsupported outcome claims. Each alternative has a row for every task. A pass is a scripted criterion pass for that row, not a completed enquiry, satisfied tenant or lawful service. The four criteria address different aspects of a journey. Combining them can summarise the fixture, but the combination cannot erase the nature or consequence of an individual failure.

The paper fixture gives structured-form PASS, PASS, FAIL, PASS and ai-concept PASS, FAIL, FAIL, FAIL. Counting all four rows yields three passes out of four and one pass out of four: 75% and 25% of these scripted checks. The difference is fifty percentage points in this fixture. It is not a measured improvement in tenant completion and not a model accuracy rate. A designer should state the denominator, the evidence kind and the criteria before presenting the percentages. Otherwise familiar numerical formatting can create more confidence than the evidence deserves.

Scroll sideways to see every column.

Examine the failures before choosing a design. The form's T-P03 failure means its voice-only route does not meet the nonvoice criterion. The AI concept points to a text route that has not been verified, so it fails that task too. Both retain HOLD_NONVOICE_HUMAN_ROUTE. The AI concept also continues without the correction step at T-P02 and asserts an unsupported outcome at T-P04. These are authored paper challenges. They do not show a deployed chatbot hallucinating, a real support team missing a message or actual people abandoning an enquiry.

The average comparison removes T-P03 because the service team considers support a separate workstream. It reports the form as three out of three and treats the human route as a future enhancement. That is a change to the evaluation question, not a correction to the arithmetic. The elite comparison retains the four-task denominator and explains that support is part of the intended journey. It can propose further form prototyping because the fixed prompts and correction path merit investigation, while keeping real pilot status held. A useful proposal and an unresolved stop can coexist.

Fairness also means resisting uneven specificity. The form should not be penalised for displaying every required step while the AI concept is described only by an attractive promise to understand users. Compare the same observable action: can the person see the requested information, correct what they supplied and choose a usable human route without an unsupported outcome claim? A later AI prototype would need equivalent detail and actual evaluation. Speculative capabilities belong in a future research question, not in the present column as if they were already demonstrated.

A disciplined comparison method has six steps. Fix the task and criterion definitions. List both exact alternative IDs and their common boundaries. Inspect all paired rows, including failures. Calculate each numerator over the complete denominator. Explain which defects are local to one design and which are shared stopping conditions. Finally write a recommendation at the evidence level actually available. These steps prevent selective arithmetic and support a reviewer who disagrees with the proposed next design. The aim is a defensible learning decision, not a competition in which one technology must win.

The public analytical method compare_designs takes the current integer fixture version and computes the complete four-task alternatives from code-owned probes. The caller cannot supply preferred outcomes or select only successful rows. inspect_probe_outcomes can reveal all four rows for a known alternative and current version. The contract rejects invalid, unknown or stale arguments as current evidence. Those constraints support an honest worksheet. They do not make the ordinary mutable teaching implementation a secure service, and they do not recognise every misleading sentence a learner might write outside its exposed methods.

Changes require a fresh comparison even if the totals stay the same. change_fixture permits the code-owned versions 1 and 2. Version 2 changes T-P02's criterion text while retaining the fixed outcomes. The unchanged percentages therefore do not prove that an old worksheet is current. A comparison includes meaning as well as numbers. Changing version clears the current hypothesis, comparison, plan and recommendation. An old returned copy may still exist, but it must be identified as stale against the current fixture. Repeating the same current version returns NO_CHANGE.

A future prototype study would need more than the fixture's counts. The team would need actual task definitions that make sense to users, suitable participation, comparable instructions and a way to record where and why a journey breaks down. It should examine effort, understanding, correction, access and support outcomes rather than selecting a convenient engagement measure. Do not invent elapsed times or satisfaction ratings for Tern. A static script has not measured these. State which proposed measure would answer which question, then leave its real observation uncompleted.

The source gds-prototyping supports exploring alternatives before committing to a production design; it does not make a code prototype production ready. gov-ai-playbook distinguishes model performance from service outcomes and permits established technologies to be suitable alternatives. nist-ai-rmf supplies a voluntary approach to context, measurement and uncertainty, with version 1.0 under revision on the retrieved overview. These are scoped references for thinking about evidence. None establishes that Tern's form is suitable for real tenants, that its AI concept has been tested or that a pilot can proceed.

The elite conclusion is conditional and useful: retain the form as a paper prototype proposal, investigate the label and correction hypotheses, and hold real use while nonvoice support and other research remain unresolved. A reviewer can choose hold-all instead if the evidence is too limited to justify the next prototype. Neither choice grants an AI pilot. The contract's later recommendation requires a fresh complete comparison and research-plan sequence. When the brief reaches someone who did not inspect the cards, preserve the failures beside the totals so the next decision remains grounded in what was actually compared.

1. Fix task and criterion definitions before comparing.
2. Retain both exact alternatives and common boundaries.
3. Inspect every paired row, including failed tasks.
4. Calculate numerator over the complete four-task denominator.
5. Separate alternative-specific defects from shared stopping conditions.
6. Recommend only the next learning step supported by the evidence.

ROLE: Adult Tern comparison analyst.
CONSTRAINTS: structured-form and ai-concept; four paired scripted criteria; no actual participants/model or tenant decision.
PROCESS: Inspect T-P01..T-P04 for both designs, calculate complete totals and retain the shared nonvoice hold.
VERIFICATION: Use current integer fixture version; preserve form PASS/PASS/FAIL/PASS and AI PASS/FAIL/FAIL/FAIL; distinguish 3/4 and 1/4 from user-success rates.
OUTPUT SCHEMA: alternativeId; taskId; criterion; scriptedOutcome; numerator; denominator; fixtureVersion; sharedHold; evidenceLimit; nextLearningStep.
FAILURE MODES: Reject denominator loss, future capability-as-evidence, stale criteria despite equal totals, and a form score-as-pilot-clearance inference. This is a paper comparison pattern.

Text equivalent: apply the same four current task definitions to structured-form and ai-concept. Count all rows to obtain three out of four and one out of four scripted passes. Both alternatives fail T-P03, so the shared nonvoice human-route hold remains regardless of the higher form total.

Scroll sideways to see every column.

Learn in your browser · Chapter 04 of 08

Describe distinct failures and preserve the preparation boundary, data questions and unresolved human route.

A product brief should describe what can go wrong for the person using the service, not only what can go wrong for the interface. In Tern, an unclear field can prevent an enquiry from being prepared. An unavailable human route can leave someone without a way to seek clarification. An unsupported outcome assertion can lead someone to believe a request has already been decided. These are distinct consequences with different design responses. Keeping them separate helps the team decide what to investigate, what to exclude and which limits must remain visible throughout the proposed journey.

Consequence mapping begins with a specific moment. At T-P04, the authored AI-concept script asserts an outcome without a supporting source. The possible design consequence is that a reader treats the assertion as a service commitment and stops seeking clarification. This is a paper failure mechanism, not an account of a tenant being harmed. Do not invent an actual promise, legal deadline or case outcome to make it dramatic. Describe the unsupported assertion, the possible interpretation and the missing authority. The brief can then exclude outcome decisions without pretending to resolve housing law.

At T-P03, both scripts fail the nonvoice human-route criterion. The consequence differs from T-P04: someone may understand the content and still be unable to reach assistance through the proposed route. A footer that says contact a person does not resolve this gap if the only route is voice or the claimed text channel is unverified. Accessibility, assistance and operational capacity interact here. The design needs a usable route, while the service needs the ability to receive and follow through on contact. Neither is established by a label in an authored transcript.

An excluded use is a boundary on what the design is meant to do. Tern excludes housing eligibility, tenancy decisions, ranking or prioritising people, legal advice, entitlement assertions, complaint outcomes and operational housing actions. These exclusions are teaching boundaries, not findings that every such use is illegal everywhere. A different real service would require its own purpose, authority, data and qualified review. Do not turn exclusions into a roadmap that promises those decisions later. First establish whether the proposed enquiry-preparation task is useful and appropriate on its own.

Scroll sideways to see every column.

Exclusions should appear at the point where a misunderstanding could arise. A brief that forbids outcome decisions while showing a reassuring outcome assertion has an internal contradiction. Removing the assertion is a design revision; burying a disclaimer elsewhere leaves the contradiction for a reader to interpret. In Tern's paper comparison, the form avoids unsupported outcome claims at T-P04, while the AI concept fails. A future design should make the preparation boundary understandable in ordinary text. It should also explain what has and has not happened, rather than using a success badge that resembles a decision.

The average consequences section says the assistant is informational and all mistakes can be passed to a human. It does not identify a route that works, the resources behind that route or the moment at which the unsupported claim becomes persuasive. The elite section identifies T-P03 and T-P04 separately, keeps both route holds and prohibits the design from asserting outcomes. It names unfinished support, privacy and supplier questions. It asks what the person can do to clarify or correct the enquiry before any handoff. These are reviewable design choices rather than broad assurances about a responsible service.

Use six steps to build this section. Locate a specific task and possible failure. Describe the interpretation or obstacle it could create. Identify the affected journey requirement without diagnosing a person. Decide which use is excluded and which safeguard or research question belongs in scope. Record the owner and evidence still needed to consider that safeguard. Finally test whether the brief and prototype contradict their own boundary. An exclusion that disappears from a shortened summary or exported table is incomplete as a communication device, even if it remains in the longer planning document.

Data choices can create consequences before any reply is written. A blank free-text box may invite someone to include more information than the preparation task needs. An AI option may involve different processing, retention or supplier conditions from a fixed form. The teaching fixture uses no actual tenant information, so it cannot resolve those conditions. A real brief would ask which information is necessary, why it is collected, who receives it, how it is retained and whether it can enter an AI system. The question about supplier training or reuse is separate from whether the interface looks helpful.

The scoped source ico-data-principles supports purpose limitation, minimisation, accuracy, security and accountability. Its retrieved overview retains a DUAA review notice, with a March 2026 update specifically to purpose limitation. Tern selects no lawful basis, controller allocation, retention period or supplier permission. The privacy research area is therefore a question to resolve, not a statement that a checkbox has made processing lawful. Do not request real documents to make the fixture more realistic. A synthetic exercise can teach the decision structure without exposing anyone's enquiry or private circumstances.

The source cma-consumer-practices explains risks of unsupported factual claims and misleading presentation in its scoped consumer-commercial guidance. Actual trader, consumer and practice classification depends on the real situation and is unresolved here. Its legal average-consumer concept does not establish that a fictional design sample represents tenants. The source eu-ai-current-context records current Commission announcements, but operative legal text was unavailable to the review. No universal ban, blanket postponement or legal classification of Tern follows. Treat these references as prompts for qualified local applicability review, not as housing advice or a stamp on the proposed design.

A research plan must preserve this distinction between planned coverage and resolved consequences. Listing privacy, supplier and support-capacity among seven required areas can produce a teaching plan draft, but it resolves none of them. A later form-prototype recommendation retains realPilotStatus=HOLD. All current factual flags stay false: actualUserResearch, actualModelRun, accessValidated, pilotAuthorised and designAccepted. A written promise of human review cannot change those facts. The implementation is an ordinary analytical teaching program, not a secure system that can establish actual authority or detect every inappropriate claim.

The final consequences handover should let another designer find the unresolved gap without reconstructing the story. Attach task IDs, failure mechanism, excluded use, proposed design change and required evidence. Carry the nonvoice route failure beside any favourable form comparison. Make the next decision explicit: continue a bounded paper investigation or hold all while obtaining actual evidence and review. No exported brief submits an enquiry or releases a service. A useful document can make an unfinished decision clearer; it must not make that decision look finished simply because its sections have been filled.

1. Locate the exact task and possible failure.
2. Describe the interpretation or obstacle it could create.
3. Identify the affected journey requirement without personal labels.
4. Separate excluded authority from in-scope design changes and questions.
5. Record the owner, support capability and evidence still needed.
6. Check brief, prototype and handover for contradictions with the boundary.

ROLE: Adult Tern consequences reviewer.
CONSTRAINTS: Enquiry preparation only; no tenant data, eligibility, legal advice, entitlement, complaint outcome, ranking or housing action.
PROCESS: Map T-P03 route failure and T-P04 unsupported outcome to distinct consequences and design questions.
VERIFICATION: Preserve both route holds, scripted evidence, unresolved privacy/supplier/capacity and all five false factual flags.
OUTPUT SCHEMA: taskId; scriptedFailure; possibleConsequence; excludedUse; proposedDesignChange; evidenceNeeded; responsibleOwner; unresolvedLimit.
FAILURE MODES: Reject disclaimer-as-route, informational-label-as-authority, research-area-as-permission and aggregate-score-as-clearance. Use source IDs with their scope; no legal classification is selected.

Text equivalent: begin with the enquiry-preparation boundary. T-P03 exposes an unverified nonvoice route requiring access and support-capacity investigation. T-P04 exposes an unsupported outcome requiring exclusion of decision authority and revision of contradictory wording. Both paths keep real pilot status held while actual evidence and authority remain unresolved.

Scroll sideways to see every column.

Learn in your browser · Chapter 05 of 08

Connect observable tasks to accountable responsibilities and stops, without treating ownership labels as approval.

Tern's sponsor wants an AI chat assistant, but a product brief needs a decision someone can defend. The invented task is for an adult to understand the limited information requested for a general enquiry, review that information and reach a human handler through a usable route. It is not deciding tenancy, entitlement, complaint outcomes or priority. Ownership means being answerable for the question, the evidence and the consequence of proceeding. A name in a spreadsheet is insufficient if that person cannot obtain evidence, challenge a claim or stop an unsupported proposal.

Separate four paper responsibilities. The brief owner maintains the task, exclusions, evidence references and competing designs. The research lead turns uncertainties into research questions and an appropriate future study. The service-support owner investigates whether human help is available and usable, including nonvoice routes and capacity. The release decision owner considers the actual evidence and authorisation needed for any real pilot. These are proposed responsibilities in a fictional team, not authenticated roles or competent appointments. The finite Tern methods do not implement a sequence of role approvals.

The first practical failure is a criterion that rewards the feature rather than the user task. A sponsor might write success means the AI answers every enquiry. That does not say whether the person can correct an omission, distinguish an unsupported outcome claim or reach someone without voice contact. Replace the feature criterion with observable task questions. T-P01 concerns identifying requested information; T-P02 concerns correction before handoff; T-P03 concerns a nonvoice human route; T-P04 concerns avoiding unsupported outcome claims. Those fixed scripted criteria do not yet establish the right criteria for real users.

Use a six-step ownership method. First write the task and excluded decisions. Second connect each criterion to a source card and identify whether its support is observation, assumption, probe or gap. Third assign the proposed evidence and service responsibilities. Fourth define what is counted, its denominator and the criterion version. Fifth identify a stop that cannot be traded away by another task's success. Sixth record the next research decision, its resources and the actual decision owner still needed. This method produces a reviewable paper plan; it supplies neither user validation nor institutional permission.

The denominator belongs with the decision. There are four fixed paired tasks for each alternative, not three convenient tasks and an awkward exception. A form passing three tasks still fails T-P03. The AI concept passing one task also fails it. The contract therefore retains HOLD_NONVOICE_HUMAN_ROUTE for both. A score can organise comparison, while a consequential stop identifies a gap that a total must not conceal. Do not infer a universal three-out-of-four product acceptance rule: these are this fixture's authored criteria and boundaries only.

Imagine a paper meeting where the brief owner presents the form's higher total and the sponsor says the support route can be fixed after launch. The support owner should ask what usable alternative a nonvoice user has now, whether it shares another barrier and who will staff it. The research lead should ask which people and settings are absent from the scripts. The decision owner should retain realPilotStatus HOLD. The meeting can authorise further paper work within the teaching scenario without claiming an actual pilot, live contact or approved service.

An average prompt says Assign an owner and give the best-scoring design a green light. An elite paper prompt has six parts. Role: product-brief decision organiser. Constraints: invented Tern evidence only, no real users, model, housing decision or pilot permission. Process: map task criteria, evidence kinds, responsibilities and non-negotiable stops. Verification: retain every task, exact denominator, fixture version and unresolved support evidence. Output schema: criterion, evidence IDs/kinds, proposed owner, counting rule, stop, research question and decision scope. Failure modes: reject assumed preferences, dropped failures, substituted scores and ownership labels treated as approval.

The research plan must address participants, nonvoice-support, assistive-technology, language, privacy, supplier and support-capacity. These are the exact seven area IDs in record_research_plan. Listing all seven produces only RESEARCH_PLAN_DRAFT under the contract, not completed research. A new accepted plan advances plan_sequence and invalidates the prior recommendation. This gives the owner a useful change question: which recommendation relied on which version of the plan? Neither a completed list nor its sequence converts planned interviews, privacy review or a support-capacity question into an observed result.

nist-ai-rmf is voluntary cross-sector guidance, with selected context and measurement sections reviewed. It supports documenting purpose, assumptions, metrics and uncertainty rather than promising design certification. gov-ai-playbook is selected UK government guidance, adapted here to the fictional product exercise. Its meaningful-control and tool-selection sections do not impose universal human approval of each chat reply. For Tern, meaningful control is made concrete by keeping recommendation scope narrow and keeping an unresolved human-route gap visible. Actual operator, jurisdiction, authority and service obligations require separate review.

An owner also needs a way to detect consequential change. Under the contract, change_fixture switches only between code-owned versions 1 and 2. Version 2 changes T-P02's criterion text while retaining its fixed outcomes. Old percentages can therefore look familiar while referring to a different criterion. A change clears current hypothesis, comparison, research plan and recommendation; old returned copies persist. Repeating the current version is NO_CHANGE. Record currentness explicitly, rather than relying on a familiar result or assuming the old export has disappeared.

The brief should specify evidence required before a future decision: actual task research, access and support tests, privacy and supplier review, accountable resources and a defined review boundary. Keep questions answerable. Instead of someone will check accessibility, propose that the research lead and support owner examine the complete nonvoice journey with affected people using appropriate settings, and report both completion obstacles and unavailable help. That is a research proposal, not recruited participants or a validated route. No contact details, legal deadlines or operational housing instructions belong in this worksheet.

Finish by making disagreement easy to record. A decision note should preserve the rejected shortcut, the evidence limitation, the stop and the next accountable question. A colleague should be able to reconstruct why a form prototype was proposed while real use stayed held. Ownership is useful when it makes the gap harder to hide and the next investigation clearer. It is not useful when a fictional role or tidy dashboard supplies confidence that the evidence does not support. All actual research, model, access, pilot and acceptance flags remain false.

Text equivalent: State the enquiry task and exclusions, retain four criteria and evidence kinds, assign proposed responsibilities and preserve both nonvoice-route failures. Record the next research decision while real use remains held.

Scroll sideways to see every column.

Learn in your browser · Chapter 06 of 08

Inspect all paired tasks and the meaning of the denominator before recommending further prototype work.

A fair prototype comparison asks whether alternative designs help with the same task under disclosed conditions. It does not ask which looks more intelligent. Tern compares a structured form with a static AI-concept transcript for general enquiry preparation. The form uses fixed prompts and preview; the transcript asks for the same limited information. Neither is a live service, operational submission or model run. Fairness here means preserving the matched tasks, authored evidence and unresolved gaps so a reader can question the result without being persuaded by conversational style.

The fixed task set has four pairs. T-P01 asks whether requested information can be identified: both scripts pass. T-P02 asks about correction before handoff: the form passes and the AI concept fails. T-P03 asks about a nonvoice human route: both fail. T-P04 asks whether unsupported outcome claims are avoided: the form passes and the AI concept fails. These eight authored probes are the whole comparison, not eight people or eight observed attempts. T-E05 remains scripted_probe_set. Keep task identity, alternative, criterion and fixture version attached to every row.

Scroll sideways to see every column.

Use six steps for a fair comparison. First state the shared task and excluded decisions. Second keep the alternatives and information boundaries comparable. Third disclose the criterion for every paired task and its current version. Fourth inspect both complete sets, including failures. Fifth calculate each numerator and denominator while preserving consequential stops. Sixth describe what the scripted evidence supports and what real research must answer. If either design changes, investigate which comparisons become stale. A result should retain enough context for someone else to repeat the reasoning without trusting the recommendation.

The paper arithmetic is three passes divided by four tasks for structured-form, or 75 percent of these scripted checks. For ai-concept it is one divided by four, or 25 percent of these scripted checks. These figures are not completion rates, preference, satisfaction, model accuracy or population estimates. They compare this authored fixture only. A difference of two script passes is useful for choosing the next prototype question, but it supplies no estimate of real benefit or cost. Both alternatives still fail the human-route criterion.

The tempting shortcut is to remove T-P03 because it is a service problem outside the interface. Doing so changes the denominator and hides a barrier in the complete user journey. Another shortcut gives the form its preview while allowing the AI concept to rely on an imagined future support feature. Compare what is actually described, not one present design against another's aspiration. Future improvements belong in a separate proposal with revised criteria and new research. No promised text route or fluent dialogue can be counted as available assistance.

Consider a paper design review where the sponsor calls T-P04 a discovered hallucination. The AI-concept transcript was authored in advance to include an unsupported outcome assertion. It is a deliberate scripted defect, not an error observed from a model. The right lesson is to inspect claim support and consequences, including whether presentation misleads someone about an outcome. It is not to announce that a tested model is unreliable. Likewise the form's no-outcome script is a criterion pass, not proof that every future form message is safe or accurate.

An average prompt says Compare the success rates and choose the more engaging AI experience. An elite paper prompt gives the role of matched-probe analyst. Constraints: fixed two alternatives, all four pairs, scripted kinds preserved, no actual users or model inference. Process: inspect each criterion, show every pass/fail and investigate denominator shortcuts. Verification: check complete rows, current fixture and arithmetic; preserve both nonvoice failures. Output schema: task, alternative, criterion, outcome, numerator, denominator, version, limitation and next research question. Failure modes: reject omitted tasks, invented transcripts, model-error claims and percentage-based pilot approval.

Under the contract, compare_designs takes the current fixture version and computes both complete alternatives from code-owned probes. A caller cannot select favourable rows or inject outcomes. inspect_probe_outcomes returns all four rows for one known alternative at the current version. Those analytical boundaries support a transparent comparison, not semantic truth detection or security assurance. Unknown alternative IDs and invalid, stale or boolean versions do not supply current evidence. Paper worksheets should follow the same discipline even without code: never let a filtered display become the undisclosed source of a total.

Version 2 changes T-P02's criterion text but retains the fixed outcomes. That is a useful challenge because an old copied percentage can look numerically correct while answering an old question. change_fixture clears the current hypothesis, comparison, plan and recommendation. Old copies remain and need a stale label relative to the current fixture. A fresh process resets version 1 without analytical results. Do not describe these memory operations as durable control, authenticated review or deletion. Current evidence means current meaning, not just a recognisable numerator.

gds-prototyping is government practice guidance used here as a method reference. It describes exploring different designs before production and distinguishes prototypes from live-service readiness. Tern is an analytical teaching aid rather than a deployed prototype or user test. nist-ai-rmf's selected voluntary measurement sections support documented methods and uncertainty; they do not certify the comparison. gov-ai-playbook permits the conclusion that established technology better addresses a goal. These sources support taking a structured form seriously instead of treating AI adoption itself as success.

A real comparison proposal must plan how order, prior experience, assistance, language and access settings could affect findings. Ask which participants are relevant, what tasks are realistic, how unsuccessful attempts will be retained and who will analyse differences. A supported session is not automatically equivalent to an unassisted service journey. These are research questions, not recruited people or an experimental protocol already accepted. Use appropriate local research and privacy review before real participation, and avoid a fictional percentage becoming the sample-size justification or an assumption about all adult tenants.

The result should end with a bounded choice and a falsifiable next question. The form is the stronger candidate in this fixed paper comparison, while both need the nonvoice support gap investigated. A form-prototype proposal can explore correction and support with actual future research; hold-all can preserve uncertainty without selecting a candidate. Neither is a pilot. A good comparison makes it possible to change the recommendation when evidence changes. It should not lock the team into either a fashionable feature or a prototype whose access failure was hidden to win the score.

Text equivalent: Compare two alternatives on the same four tasks. Preserve all eight scripted rows and the current criterion version. Form passes three of four and AI one of four; both fail nonvoice support. Use the result to plan research, not authorise real use.

Scroll sideways to see every column.

Learn in your browser · Chapter 07 of 08

Investigate the whole enquiry journey and the support behind a channel label before claiming usable access.

Access is whether a person can complete the intended journey, including getting help when the interface is insufficient. Tern's task ends at a human handoff, not at a well-worded screen. The invented form and AI concept both fail T-P03, reaching a nonvoice human route. One script offers voice contact only; the other points to an unverified text route. Neither provides evidence that suitable assistance exists. This is a deliberate design gap in authored material, not a discovered failure affecting a real tenant or a tested accessibility result.

Do not collapse access into a single persona or a binary accessible checkbox. Someone may need keyboard operation, screen-reader compatibility, easier reading, another language, a nonvoice channel or help because they lack digital confidence or internet access. These needs can overlap without being identical. Nonvoice support delivered online does not automatically solve nononline access. A telephone number is not usable for everyone, while an in-person proposal needs its own availability and practical review. Tern supplies no real person, diagnosis, contact or support site.

Use six steps to review the journey. First identify the task from first explanation through correction and human handoff. Second list barriers and missing evidence at each stage, rather than assigning a deficit to the person. Third distinguish interface access, language/content and assistance needs. Fourth connect each proposed route to a responsible support owner and capacity question. Fifth plan research with affected people and appropriate settings, including unsuccessful journeys. Sixth record stop and decision conditions without claiming the route is available. The method produces questions for real investigation, not a validated service.

A useful ordinary-text alternative describes what information is requested, what can be reviewed or corrected and what the proposed human option does. It should keep uncertainty visible rather than promise an outcome. For a keyboard or screen-reader journey, ask how focus, labels, errors, preview and status changes can be understood across the complete process. For easier-reading or language review, ask whether the person can explain the requested task in their own words without being led. These proposed checks do not establish translation quality, technical conformance or actual comprehension.

Consider a paper redesign that adds a button labelled Text a human. The sponsor calls T-P03 repaired because a nonvoice word now appears. The support owner should ask who receives it, whether that route is staffed, what happens when it is unavailable, what privacy and record handling apply and whether the person can find and use it. The research lead should ask which affected people can test the complete journey. Until actual evidence answers those questions, the button is a design proposal. It cannot retroactively change the fixed probe from FAIL to PASS.

An average prompt says Add an accessible human-help link and mark the flow inclusive. An elite paper prompt gives the role of end-to-end access reviewer. Constraints: fictional journey only, no real contacts, diagnosis, participant evidence or accepted route. Process: map text, keyboard/screen-reader, language, low-digital, nonvoice and human-support barriers. Verification: distinguish proposed labels from demonstrated route availability, retain both T-P03 failures and all evidence kinds. Output schema: journey stage, barrier, proposed route, owner, research question, capacity dependency and stop. Failure modes: reject voice-only universal access, invented testing, missing offline needs and a label counted as availability.

inclusive-accessibility groups government Service Standard guidance, scoped public-sector requirements and selected WCAG 2.2 criteria. These have different status. The Service Standard concerns online/offline access and affected-user research. The requirements page applies to in-scope public bodies, with exemptions and separate GB/NI equality context; it is not automatically the legal regime for every private tenant service. Selected keyboard, focus and status-message criteria help define technical questions. Full-page and complete-process conformance cannot be inferred from a diagram or one usable screen. No operator classification or full audit is completed here.

assisted-digital-support is government practice guidance about researched support needs, including phone, in person and sometimes webchat. Adapt its method rather than treating its channel list as universal permission or proof of usability. Confidence, trust, skills and internet access can create barriers even when technical interface criteria are met. A proposed channel may also share the same unavailable staff or digital dependency as the primary route. The service-support owner must investigate actual resources and continuity; the workbook has not verified capacity, availability, response time or any real support arrangement.

Plan actual research through questions, not fabricated findings. gds-research-planning recommends turning assumptions into research questions and considering participant groups and assistance. Its disability-session supporting guidance encourages asking about individual requirements and allowing participants' own assistive technology/settings. No one has been recruited here. The future research lead must arrange appropriate ethical, accessible participation and privacy handling under the actual organisation's process. Do not infer a statutory participant minimum, treat a fixed script as representative or use the fictional sponsor's preference claim to select only people comfortable with chat.

The seven-area research plan makes the access gap accountable: participants, nonvoice-support, assistive-technology, language, privacy, supplier and support-capacity. For each, write a question, proposed method, evidence needed and owner, plus what remains unapproved. record_research_plan accepts the exact complete set to produce a draft and a new plan_sequence. Missing an area holds the plan, while completion still leaves accessValidated false. A new accepted plan invalidates a prior recommendation. Method validation checks the list; it does not judge the adequacy of a real study or approve its people and data.

Privacy is part of access rather than a reason to collect every detail. Ask what information is necessary for a research activity or proposed enquiry handoff, who sees it and how long it persists. ico-data-principles has a DUAA review notice and a specific March 2026 purpose-limitation update, not a declaration that every related page is final. The fixture selects no actual lawful basis, consent process, retention period or supplier permission. An appropriate actual review must distinguish agreeing to participate from the applicable processing grounds and any separate service duties.

A strong access section can conclude not yet. State the failed scripted task, proposed alternatives, missing route/capacity evidence, affected journeys to investigate and the next decision. Preserve easier-reading and nononline questions rather than assuming a technical interface fix solves them. The form's better total may justify further paper exploration, while both designs retain the same real-use hold. AccessValidated, actualUserResearch, actualModelRun, pilotAuthorised and designAccepted remain false. That explicit record lets the team improve the proposal without presenting absent people, unseen testing or unimplemented human help as evidence of success.

Text equivalent: Map explanation, correction and handoff, then distinguish access barriers and route/capacity questions. Plan appropriate real research across seven areas. Both fixed nonvoice checks remain failed; access and pilot acceptance stay unvalidated.

Scroll sideways to see every column.

Learn in your browser · Chapter 08 of 08

Produce a traceable product brief with a bounded prototype choice, actual research questions and a held real-use decision.

This capstone supplies a complete fictional product brief for Tern-Adult-Enquiry-Training, purpose design-brief-teaching. Its proposed task is to help an adult understand the limited information requested for a general enquiry, review or correct it and reach a human handler through a usable route. It does not decide eligibility, tenancy, entitlement, priority, complaints or legal outcomes. The brief recommends further bounded form-prototype work, while realPilotStatus remains HOLD. It describes a traceable decision and research plan, not a launched housing service or professional acceptance.

The need hypothesis is: an adult preparing a general enquiry may need clearer requested information, correction before handoff and suitable human help, rather than a particular interface. T-E01 and T-E02 motivate label/correction questions; T-E04 identifies an authored access gap. All are synthetic. T-E03's everyone prefers chat remains a stakeholder assumption, not evidence of preference. gds-user-needs is government guidance adapted as a method: goals should not prescribe the solution, and assumptions need research. No fictional card establishes an actual tenant need or replaces likely-user investigation.

The evidence register below is part of the brief, with every kind visible. Provenance is the authored Tern fixture, not a recorded session or commercial dataset. list_evidence_cards is the contracted way to inspect copied cards. draft_need_hypothesis can produce only a hypothesis; T-E03 alone holds as assumption-only. Adding a synthetic card does not turn the sponsor's proposition into observed preference. Record which claim each card supports and what it cannot establish. The research-gap register belongs beside the evidence, so absence of participants, access or supplier review remains visible at recommendation time.

Scroll sideways to see every column.

The alternatives are structured-form and ai-concept, both confined to enquiry preparation. The paired task register retains T-P01 information identification, T-P02 correction, T-P03 nonvoice human route and T-P04 unsupported outcome claims. The paper outcomes are form PASS/PASS/FAIL/PASS and AI PASS/FAIL/FAIL/FAIL. That gives three of four and one of four, or 75 and 25 percent of scripted checks only. There are eight authored probes, no model or people. Both retain HOLD_NONVOICE_HUMAN_ROUTE, which the form's higher total cannot override.

Use six steps to defend the recommendation. First restate the task, evidence kinds and exclusions. Second show the full matched comparison and current criterion version. Third explain why a specific paper prototype is the next useful investigation. Fourth identify all missing research and support evidence with proposed owners. Fifth state stop, change and recommendation conditions. Sixth distinguish the prototype proposal, any future real pilot decision and design acceptance. A completed brief is valuable because its recommendation can be challenged. It must not be written as if a green score supplies consent, legal clearance or live resources.

An average capstone prompt says Use the best result to write an AI launch brief. An elite paper prompt has six parts. Role: evidence-grounded product-brief writer. Constraints: six fictional cards, fixed alternatives/probes, no validated need, real user, model, housing decision or release approval. Process: assemble need, comparison, owners, seven-area research, stops and change record. Verification: preserve card kinds, complete denominators, current fixture/plan sequence and both route failures. Output schema: hypothesis, source IDs/kinds, alternatives, task outcomes, owners, gaps, research and recommendation scope. Failure modes: hold unsupported AI choice, assumption promotion, stale copies, missing support and percentage-based acceptance.

Proposed ownership is explicit: brief owner maintains traceability and comparison; research lead prepares actual study questions and appropriate participation; support owner investigates usable routes and resources; an actual release decision owner and relevant data/legal/supplier reviewers remain to be established. These responsibilities are not authenticated approvals in Tern. The seven-area plan below provides questions, proposed methods and evidence targets rather than invented findings. It does not recruit participants, obtain consent, select processing grounds or validate a channel. Every real acceptance flag remains false even when the administrative plan is complete.

Scroll sideways to see every column.

The paper analytical sequence is to inspect cards, draft a bounded hypothesis, compare all tasks at the current fixture, record all seven research areas and use the current returned plan_sequence for draft_brief_recommendation. Choose form-prototype for FORM_PROTOTYPE_PROPOSAL or hold-all for HOLD_ALL_PENDING_RESEARCH. The contract accepts neither an AI choice nor caller-supplied acceptance. export_brief requires the current recommendation and returns a fresh teaching brief. These are specified method boundaries and expected paper outcomes while authoring; no execution, test count or successful prototype research is claimed in this chapter.

The change record preserves fixture version 1 and requires reanalysis after change_fixture moves to version 2. T-P02 criterion text changes while outcomes stay fixed, so percentages alone cannot establish currentness. The change clears hypothesis, comparison, plan and recommendation; old returned copies must be marked stale relative to the current fixture. A new complete research plan advances sequence and invalidates a prior recommendation. A validation failure handled inside a method clears its dependent recommendation; Python argument-binding TypeError before the method body leaves existing state intact. A fresh process starts at version 1 with no analytical results. These are ordinary memory boundaries, not durable identity, deletion or secure enforcement.

Any future real pilot proposal needs actual participants and tasks, authorised ethical/privacy handling, relevant operator/jurisdiction review, exclusions, support resources, access evidence, measurable criteria, monitoring and an accountable decision owner. The proposed study should retain failed journeys, correction obstacles and unavailable help rather than select only comfortable chat users. Supplier questions include processing, training reuse, logs, retention, transfers, security and exit. A bounded export can aid record organisation, but cannot prove migration, deletion, consent or sovereign control. A proposed Mickai service could organise records digitisation and permissions; no live product capability is certified here.

Contextual sources do not decide this service's law. cma-consumer-practices gives selected UK consumer-claim guidance: evidence and presentation matter, but no trader/practice classification or tenancy advice is supplied. ico-data-principles retains its DUAA review notice and selects no actual privacy basis. eu-ai-current-context is current Commission explanation with operative-text retrieval unresolved, not a universal delay or exemption. Government Service Manual and playbook methods are adaptations; inclusive-accessibility has distinct public-body and technical scopes. Actual local requirements and qualified applicability remain open, alongside research and service acceptance.

Teach the brief back by naming the rejected shortcut: a higher scripted total cannot authorise real use while a shared human route fails. Explain what would change the proposal and who must bring evidence. The capstone and written tasks are ungraded. The linked official twenty-question knowledge exam requires strictly above 80 percent, so 16/20 fails and 17/20 passes. Its public availability depends on the completed checked release. A knowledge result would not certify a designer, accepted product or legal compliance. The finished brief records a form-prototype proposal with real pilot held and a concrete research agenda.

Text equivalent: Preserve six cards and their five distinct kinds and the complete paired comparison. Link seven research areas to proposed responsibilities. Use the current fixture and plan sequence for a bounded recommendation/export. The form prototype is proposed while both nonvoice failures and real pilot HOLD remain.

Scroll sideways to see every column.

Scroll sideways to see every column.

python -B -X utf8 -m unittest -v test_tern_lab.py
python -B -X utf8 tern_lab.py

Scroll sideways to see every column.

# Tern Brief Comparator

Original adult design training for a fictional general-enquiry journey. It is a finite analytical worksheet, not a tenant chatbot or housing service. No participant, tenant record, address, model, network, upload, external form or operational submission is used.

Requires Python 3.10 or later and its standard library. Keep these four learner files together: `tern_lab.py`, `test_tern_lab.py`, `fixture.json`, `README.md`. Run `python -B -X utf8 tern_lab.py` for the complete JSON demo, and `python -B -X utf8 -m unittest -v test_tern_lab` for author tests. No installation is needed. Tests use the platform temporary directory; optional `TERN_TEST_TEMP` selects an existing writable temporary directory. Creator execution sets TEMP/TMP externally to M:; learners do not need that drive.

The six cards explicitly distinguish authored observations, sponsor assumption, access gap, scripted probes and research gaps. Four matched tasks test each alternative. The fixed structured-form outcomes are PASS/PASS/FAIL/PASS; the static AI concept gives PASS/FAIL/FAIL/FAIL. Counts are 3/4 and 1/4 (75% and 25%) of scripted criteria only. Both fail the nonvoice human-route criterion. The higher form total cannot establish available assistance or a real user preference. These are not people, model accuracy or measured service success.

## Work through the comparison

Import `Tern` and `AREAS` from `tern_lab`. Create `t = Tern()`. Read `t.list_evidence_cards()`. Draft a hypothesis with `t.draft_need_hypothesis(['T-E01', 'T-E02'], 'T-P02', 1)`; T-E03 alone is held as an assumption. Inspect all four rows with `t.inspect_probe_outcomes('ai-concept', 1)`. Use `t.compare_designs(1)` for both complete denominators. Record a plan using `p = t.record_research_plan(list(AREAS), 1)`. Then `t.draft_brief_recommendation('form-prototype', 1, p['planSequence'])` or `'hold-all'`, and `t.export_brief(1)`. No actual research is performed by a completed plan.

All seven research areas are required: participants, nonvoice-support, assistive-technology, language, privacy, supplier, support-capacity. Plans increase a sequence counter. A new plan or a plan call that enters the method and fails validation clears the current recommendation; incomplete plans cannot reuse an earlier completed plan. Recommendations require a current complete comparison and completed plan, and always retain realPilotStatus HOLD. There is no AI approval choice. Actual research, model execution, access validation, pilot authorisation and design acceptance flags remain false.

`t.change_fixture(2)` changes T-P02's criterion wording, not its outcomes, and clears current analytical work. Repeating the current version is NO_CHANGE. Redo comparison, plan and recommendation at version 2; do not reuse a version-1 criterion or old plan sequence. Returning to version 1 also clears work. Old returned JSON copies still exist. A new Python process starts at version 1 with no work and sequence zero; exported files are not erased or recalled.

The fixed local fixture is validated against code-owned fields, exact types and values on reads, including duplicate keys. There is no arbitrary path argument. When a call binds to the method signature and fails validation inside the method, it clears the recommendation; comparison-validation failures clear the comparison, and plan-validation failures clear the completed plan. Unknown, extra or missing arguments can instead raise TypeError before the method body runs, leaving existing state unchanged. Such argument-binding errors are not recorded holds or evidence checks. Inventory and successful probe inspection do not establish a comparison. Returned objects are separate copies. This is not semantic truth detection: no free-text classifier decides whether a claim is honest. Ordinary Python attributes can be changed by a caller and are not an enforced secure store, authentication or durable identity. Do not use this exercise as a security boundary.

Actual participants, ethical/privacy and applicable legal review, supplier conditions, assistive technology, language and end-to-end access checks, support capacity and service-owner decisions remain unresolved. The exercise gives no housing, eligibility, urgency, prioritisation or legal advice. A teaching brief is neither research consent nor migration, deletion, sovereignty, release approval or an accepted design. Author tests are not independent approval.

{
  "project": "Tern-Adult-Enquiry-Training",
  "purpose": "design-brief-teaching",
  "fixtureVersion": 1,
  "cards": [
    {
      "id": "T-E01",
      "kind": "synthetic_observation",
      "content": "An authored adult pauses at the unexplained description label; this is a label hypothesis, not a real session.",
      "provenance": "Tern authored synthetic evidence card"
    },
    {
      "id": "T-E02",
      "kind": "synthetic_observation",
      "content": "An authored preview permits correction of an omitted detail; this supports a research question, not a measured improvement.",
      "provenance": "Tern authored synthetic evidence card"
    },
    {
      "id": "T-E03",
      "kind": "stakeholder_assumption",
      "content": "The fictional sponsor says every tenant prefers chat; this remains a proposition to research.",
      "provenance": "Tern authored synthetic evidence card"
    },
    {
      "id": "T-E04",
      "kind": "synthetic_access_gap",
      "content": "The planned human route is voice only; nonvoice and nononline alternatives are unverified.",
      "provenance": "Tern authored synthetic evidence card"
    },
    {
      "id": "T-E05",
      "kind": "scripted_probe_set",
      "content": "Eight authored probes compare four matched tasks for each design; neither people nor model outputs are represented.",
      "provenance": "Tern authored synthetic evidence card"
    },
    {
      "id": "T-E06",
      "kind": "research_gap_register",
      "content": "Recruitment, participant evidence, assistive technology, language, lawful handling, supplier terms and support capacity remain unresolved.",
      "provenance": "Tern authored synthetic evidence card"
    }
  ],
  "versions": {
    "1": [
      {
        "taskId": "T-P01",
        "alternativeId": "structured-form",
        "criterionId": "T-C01",
        "criterion": "Identify the same limited requested information.",
        "outcome": "PASS",
        "observation": "Fixed prompts identify the requested information.",
        "fixtureVersion": 1,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      },
      {
        "taskId": "T-P02",
        "alternativeId": "structured-form",
        "criterionId": "T-C02",
        "criterion": "Allow correction before the proposed handoff.",
        "outcome": "PASS",
        "observation": "The authored preview permits correction.",
        "fixtureVersion": 1,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      },
      {
        "taskId": "T-P03",
        "alternativeId": "structured-form",
        "criterionId": "T-C03",
        "criterion": "Provide a verified nonvoice human route.",
        "outcome": "FAIL",
        "observation": "Only a voice route is shown.",
        "fixtureVersion": 1,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      },
      {
        "taskId": "T-P04",
        "alternativeId": "structured-form",
        "criterionId": "T-C04",
        "criterion": "Avoid asserting unsupported outcomes.",
        "outcome": "PASS",
        "observation": "The fixed form promises no outcome.",
        "fixtureVersion": 1,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      },
      {
        "taskId": "T-P01",
        "alternativeId": "ai-concept",
        "criterionId": "T-C01",
        "criterion": "Identify the same limited requested information.",
        "outcome": "PASS",
        "observation": "The static authored transcript asks for the same information.",
        "fixtureVersion": 1,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      },
      {
        "taskId": "T-P02",
        "alternativeId": "ai-concept",
        "criterionId": "T-C02",
        "criterion": "Allow correction before the proposed handoff.",
        "outcome": "FAIL",
        "observation": "The script continues without the correction step.",
        "fixtureVersion": 1,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      },
      {
        "taskId": "T-P03",
        "alternativeId": "ai-concept",
        "criterionId": "T-C03",
        "criterion": "Provide a verified nonvoice human route.",
        "outcome": "FAIL",
        "observation": "The text route is unverified.",
        "fixtureVersion": 1,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      },
      {
        "taskId": "T-P04",
        "alternativeId": "ai-concept",
        "criterionId": "T-C04",
        "criterion": "Avoid asserting unsupported outcomes.",
        "outcome": "FAIL",
        "observation": "The authored transcript asserts an outcome without support.",
        "fixtureVersion": 1,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      }
    ],
    "2": [
      {
        "taskId": "T-P01",
        "alternativeId": "structured-form",
        "criterionId": "T-C01",
        "criterion": "Identify the same limited requested information.",
        "outcome": "PASS",
        "observation": "Fixed prompts identify the requested information.",
        "fixtureVersion": 2,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      },
      {
        "taskId": "T-P02",
        "alternativeId": "structured-form",
        "criterionId": "T-C02",
        "criterion": "Present a reviewable correction step before the proposed handoff, retaining the original detail.",
        "outcome": "PASS",
        "observation": "The authored preview permits correction.",
        "fixtureVersion": 2,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      },
      {
        "taskId": "T-P03",
        "alternativeId": "structured-form",
        "criterionId": "T-C03",
        "criterion": "Provide a verified nonvoice human route.",
        "outcome": "FAIL",
        "observation": "Only a voice route is shown.",
        "fixtureVersion": 2,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      },
      {
        "taskId": "T-P04",
        "alternativeId": "structured-form",
        "criterionId": "T-C04",
        "criterion": "Avoid asserting unsupported outcomes.",
        "outcome": "PASS",
        "observation": "The fixed form promises no outcome.",
        "fixtureVersion": 2,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      },
      {
        "taskId": "T-P01",
        "alternativeId": "ai-concept",
        "criterionId": "T-C01",
        "criterion": "Identify the same limited requested information.",
        "outcome": "PASS",
        "observation": "The static authored transcript asks for the same information.",
        "fixtureVersion": 2,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      },
      {
        "taskId": "T-P02",
        "alternativeId": "ai-concept",
        "criterionId": "T-C02",
        "criterion": "Present a reviewable correction step before the proposed handoff, retaining the original detail.",
        "outcome": "FAIL",
        "observation": "The script continues without the correction step.",
        "fixtureVersion": 2,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      },
      {
        "taskId": "T-P03",
        "alternativeId": "ai-concept",
        "criterionId": "T-C03",
        "criterion": "Provide a verified nonvoice human route.",
        "outcome": "FAIL",
        "observation": "The text route is unverified.",
        "fixtureVersion": 2,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      },
      {
        "taskId": "T-P04",
        "alternativeId": "ai-concept",
        "criterionId": "T-C04",
        "criterion": "Avoid asserting unsupported outcomes.",
        "outcome": "FAIL",
        "observation": "The authored transcript asserts an outcome without support.",
        "fixtureVersion": 2,
        "evidenceKind": "scripted_probe",
        "sourceCardIds": [
          "T-E05"
        ],
        "provenance": "Tern authored synthetic probe"
      }
    ]
  }
}

"""Tern: an offline, authored design comparison, not a tenant service."""
import copy
import json
from pathlib import Path

AREAS = ('participants', 'nonvoice-support', 'assistive-technology', 'language', 'privacy', 'supplier', 'support-capacity')
FLAGS = dict(actualUserResearch=False, actualModelRun=False, accessValidated=False,
             pilotAuthorised=False, designAccepted=False)
LIMITS = ["Authored synthetic cards and scripted probes only; no participants or model.",
          "Percentages count four fixed criteria, not user success or population evidence.",
          "Both nonvoice human routes fail; actual access and support capacity are unresolved.",
          "Research planning does not perform research, legal review or authorise a pilot.",
          "Mutable process memory is not an enforced secure store; old copies remain."]

def _baseline():
    cards = [
        ('synthetic_observation', 'An authored adult pauses at the unexplained description label; this is a label hypothesis, not a real session.'),
        ('synthetic_observation', 'An authored preview permits correction of an omitted detail; this supports a research question, not a measured improvement.'),
        ('stakeholder_assumption', 'The fictional sponsor says every tenant prefers chat; this remains a proposition to research.'),
        ('synthetic_access_gap', 'The planned human route is voice only; nonvoice and nononline alternatives are unverified.'),
        ('scripted_probe_set', 'Eight authored probes compare four matched tasks for each design; neither people nor model outputs are represented.'),
        ('research_gap_register', 'Recruitment, participant evidence, assistive technology, language, lawful handling, supplier terms and support capacity remain unresolved.')]
    criteria = ['Identify the same limited requested information.',
                'Allow correction before the proposed handoff.',
                'Provide a verified nonvoice human route.',
                'Avoid asserting unsupported outcomes.']
    observations = {
        'structured-form': ['Fixed prompts identify the requested information.', 'The authored preview permits correction.', 'Only a voice route is shown.', 'The fixed form promises no outcome.'],
        'ai-concept': ['The static authored transcript asks for the same information.', 'The script continues without the correction step.', 'The text route is unverified.', 'The authored transcript asserts an outcome without support.']}
    versions = {}
    for version in (1, 2):
        rows = []
        for alternative, outcomes in [('structured-form', ['PASS', 'PASS', 'FAIL', 'PASS']), ('ai-concept', ['PASS', 'FAIL', 'FAIL', 'FAIL'])]:
            for i, outcome in enumerate(outcomes):
                criterion = criteria[i]
                if version == 2 and i == 1:
                    criterion = 'Present a reviewable correction step before the proposed handoff, retaining the original detail.'
                rows.append(dict(taskId=f'T-P{i+1:02}', alternativeId=alternative,
                                 criterionId=f'T-C{i+1:02}', criterion=criterion,
                                 outcome=outcome, observation=observations[alternative][i],
                                 fixtureVersion=version, evidenceKind='scripted_probe',
                                 sourceCardIds=['T-E05'], provenance='Tern authored synthetic probe'))
        versions[str(version)] = rows
    return dict(project='Tern-Adult-Enquiry-Training', purpose='design-brief-teaching',
                fixtureVersion=1, cards=[dict(id=f'T-E{i+1:02}', kind=kind, content=content,
                provenance='Tern authored synthetic evidence card') for i, (kind, content) in enumerate(cards)],
                versions=versions)

def _no_duplicates(pairs):
    result = {}
    for key, value in pairs:
        if key in result:
            raise ValueError('duplicate JSON key')
        result[key] = value
    return result

def _exact(actual, expected):
    if type(actual) is not type(expected):
        return False
    if isinstance(expected, dict):
        return actual.keys() == expected.keys() and all(_exact(actual[k], v) for k, v in expected.items())
    if isinstance(expected, list):
        return len(actual) == len(expected) and all(_exact(a, b) for a, b in zip(actual, expected))
    return actual == expected

class Tern:
    def __init__(self):
        self.fixture_version = 1
        self.plan_sequence = 0
        self._hypothesis = self._comparison = self._plan = self._recommendation = None

    def _output(self, status, **values):
        return copy.deepcopy(dict(status=status, fixtureVersion=self.fixture_version,
                                  realPilotStatus='HOLD', limitations=LIMITS, **FLAGS, **values))

    def _hold(self, reason):
        self._recommendation = None
        return self._output('HOLD', reason=reason)

    def _load(self):
        try:
            data = json.loads(Path(__file__).with_name('fixture.json').read_text(encoding='utf-8'),
                              object_pairs_hook=_no_duplicates)
            return data if _exact(data, _baseline()) else None
        except (OSError, ValueError, RecursionError):
            return None

    def _current(self, version):
        return type(version) is int and version == self.fixture_version

    def list_evidence_cards(self):
        data = self._load()
        return copy.deepcopy(data['cards']) if data else self._hold('INVALID_FIXTURE')

    def draft_need_hypothesis(self, evidence_ids, task_id, fixture_version):
        self._hypothesis = None
        self._recommendation = None
        if not self._current(fixture_version):
            return self._hold('INVALID_VERSION')
        if type(task_id) is not str or task_id not in [f'T-P{i:02}' for i in range(1, 5)]:
            return self._hold('UNKNOWN_TASK')
        if type(evidence_ids) is not list or not evidence_ids or any(type(x) is not str or x not in [f'T-E{i:02}' for i in range(1, 7)] for x in evidence_ids):
            return self._hold('INVALID_EVIDENCE_IDS')
        if len(evidence_ids) != len(set(evidence_ids)):
            return self._hold('DUPLICATE_EVIDENCE_IDS')
        data = self._load()
        if not data:
            return self._hold('INVALID_FIXTURE')
        cards = [c for c in data['cards'] if c['id'] in evidence_ids]
        result = self._output('HOLD_ASSUMPTION_ONLY' if evidence_ids == ['T-E03'] else 'NEED_HYPOTHESIS',
                             sourceCardIds=list(evidence_ids), taskId=task_id, evidenceCards=cards,
                             evidenceKind=[c['kind'] for c in cards], needValidated=False)
        self._hypothesis = copy.deepcopy(result)
        return result

    def inspect_probe_outcomes(self, alternative_id, fixture_version):
        if type(alternative_id) is not str or alternative_id not in ('structured-form', 'ai-concept'):
            return self._hold('UNKNOWN_ALTERNATIVE')
        if not self._current(fixture_version):
            return self._hold('INVALID_VERSION')
        data = self._load()
        if not data:
            return self._hold('INVALID_FIXTURE')
        return self._output('SCRIPTED_PROBE_OUTCOMES', alternativeId=alternative_id,
                            rows=[r for r in data['versions'][str(self.fixture_version)] if r['alternativeId'] == alternative_id])

    def compare_designs(self, fixture_version):
        self._comparison = self._recommendation = None
        if not self._current(fixture_version):
            return self._hold('INVALID_VERSION')
        data = self._load()
        if not data:
            return self._hold('INVALID_FIXTURE')
        alternatives = []
        for alternative in ('structured-form', 'ai-concept'):
            rows = [r for r in data['versions'][str(self.fixture_version)] if r['alternativeId'] == alternative]
            numerator = sum(r['outcome'] == 'PASS' for r in rows)
            alternatives.append(dict(alternativeId=alternative, rows=rows, numerator=numerator,
                                     denominator=len(rows), percent=100*numerator/len(rows),
                                     routeStatus='HOLD_NONVOICE_HUMAN_ROUTE'))
        result = self._output('SCRIPTED_COMPARISON', alternatives=alternatives,
                             evidenceKind='scripted_probe_set', sourceCardIds=['T-E05'])
        self._comparison = copy.deepcopy(result)
        return result

    def record_research_plan(self, areas, fixture_version):
        self._plan = self._recommendation = None
        if not self._current(fixture_version):
            return self._hold('INVALID_VERSION')
        if type(areas) is not list or any(type(a) is not str or a not in AREAS for a in areas):
            return self._hold('INVALID_RESEARCH_AREAS')
        if len(areas) != len(set(areas)):
            return self._hold('DUPLICATE_RESEARCH_AREAS')
        if not self._load():
            return self._hold('INVALID_FIXTURE')
        missing = [a for a in AREAS if a not in areas]
        if missing:
            return self._output('HOLD_INCOMPLETE_RESEARCH_PLAN', missingAreas=missing)
        self.plan_sequence += 1
        result = self._output('RESEARCH_PLAN_DRAFT', areas=list(AREAS), planSequence=self.plan_sequence,
                             performedResearch=False)
        self._plan = copy.deepcopy(result)
        return result

    def draft_brief_recommendation(self, choice, fixture_version, plan_sequence):
        self._recommendation = None
        if not self._current(fixture_version):
            return self._hold('INVALID_VERSION')
        if type(choice) is not str or choice not in ('form-prototype', 'hold-all'):
            return self._hold('UNSUPPORTED_CHOICE')
        if type(plan_sequence) is not int or not self._plan or plan_sequence != self.plan_sequence:
            return self._hold('INVALID_PLAN_SEQUENCE')
        if not self._comparison:
            return self._hold('NO_CURRENT_COMPARISON')
        if not self._load():
            return self._hold('INVALID_FIXTURE')
        result = self._output('FORM_PROTOTYPE_PROPOSAL' if choice == 'form-prototype' else 'HOLD_ALL_PENDING_RESEARCH',
                             recommendationScope='Synthetic teaching proposal only', choice=choice,
                             planSequence=plan_sequence, comparison=self._comparison, researchPlan=self._plan,
                             failedNonvoiceRoutes=['structured-form', 'ai-concept'])
        self._recommendation = copy.deepcopy(result)
        return result

    def change_fixture(self, fixture_version):
        if type(fixture_version) is not int or fixture_version not in (1, 2):
            return self._hold('INVALID_VERSION')
        if not self._load():
            return self._hold('INVALID_FIXTURE')
        if fixture_version == self.fixture_version:
            return self._output('NO_CHANGE')
        self.fixture_version = fixture_version
        self._hypothesis = self._comparison = self._plan = self._recommendation = None
        return self._output('FIXTURE_CHANGED')

    def export_brief(self, fixture_version):
        if not self._current(fixture_version):
            return self._hold('INVALID_VERSION')
        data = self._load()
        if not data:
            return self._hold('INVALID_FIXTURE')
        if not self._recommendation:
            return self._hold('NO_CURRENT_RECOMMENDATION')
        return self._output('TEACHING_BRIEF', project=data['project'], purpose=data['purpose'],
                            evidenceCards=data['cards'], hypothesis=self._hypothesis,
                            recommendation=self._recommendation, unresolvedGaps=list(AREAS))

def demo():
    tern = Tern()
    cards = tern.list_evidence_cards()
    hypothesis = tern.draft_need_hypothesis(['T-E01', 'T-E02'], 'T-P02', 1)
    comparison = tern.compare_designs(1)
    plan = tern.record_research_plan(list(AREAS), 1)
    recommendation = tern.draft_brief_recommendation('form-prototype', 1, plan['planSequence'])
    return dict(cards=cards, hypothesis=hypothesis, comparison=comparison,
                researchPlan=plan, recommendation=recommendation, brief=tern.export_brief(1))

if __name__ == '__main__':
    print(json.dumps(demo(), indent=2))

"""Author checks of finite teaching invariants; not independent lab approval."""
import copy
import json
import os
from pathlib import Path
import shutil
import subprocess
import sys
import tempfile
import unittest
from unittest.mock import patch
import tern_lab as lab

class TernTests(unittest.TestCase):
    def setUp(self):
        self.t = lab.Tern()

    def ready(self, choice='form-prototype'):
        self.t.compare_designs(1)
        p = self.t.record_research_plan(list(lab.AREAS), 1)
        return self.t.draft_brief_recommendation(choice, 1, p['planSequence'])

    def held(self, value):
        self.assertTrue(value['status'].startswith('HOLD'))
        for key in lab.FLAGS:
            self.assertIs(value[key], False)

    def test_paired_denominator_not_people(self):
        c = self.t.compare_designs(1)
        self.assertEqual([(a['numerator'], a['denominator'], a['percent']) for a in c['alternatives']], [(3,4,75), (1,4,25)])
        self.assertEqual([r['taskId'] for r in c['alternatives'][0]['rows']], [r['taskId'] for r in c['alternatives'][1]['rows']])

    def test_superior_total_does_not_remove_route_hold(self):
        r = self.ready()
        self.assertEqual(r['failedNonvoiceRoutes'], ['structured-form','ai-concept'])
        self.assertEqual(r['realPilotStatus'], 'HOLD')
        self.assertTrue(all(a['routeStatus']=='HOLD_NONVOICE_HUMAN_ROUTE' for a in r['comparison']['alternatives']))

    def test_assumption_alone(self):
        r = self.t.draft_need_hypothesis(['T-E03'], 'T-P01', 1)
        self.assertEqual(r['status'], 'HOLD_ASSUMPTION_ONLY')
        self.assertFalse(r['needValidated'])

    def test_mixed_evidence_keeps_assumption(self):
        r = self.t.draft_need_hypothesis(['T-E01','T-E03'], 'T-P01', 1)
        self.assertEqual(r['evidenceKind'], ['synthetic_observation','stakeholder_assumption'])
        self.assertFalse(r['needValidated'])

    def test_cards_are_not_participants(self):
        cards = self.t.list_evidence_cards()
        self.assertEqual(len(cards),6)
        self.assertEqual(cards[5]['kind'],'research_gap_register')
        self.assertTrue(all('synthetic' in c['provenance'] for c in cards))

    def test_cards_copy_isolation(self):
        cards = self.t.list_evidence_cards(); cards[2]['kind']='actual_research'
        self.assertEqual(self.t.list_evidence_cards()[2]['kind'],'stakeholder_assumption')

    def test_empty_evidence(self): self.held(self.t.draft_need_hypothesis([], 'T-P01',1))
    def test_duplicate_evidence(self): self.held(self.t.draft_need_hypothesis(['T-E01','T-E01'],'T-P01',1))
    def test_evidence_type(self): self.held(self.t.draft_need_hypothesis(('T-E01',),'T-P01',1))
    def test_unknown_evidence(self): self.held(self.t.draft_need_hypothesis(['T-E07'],'T-P01',1))
    def test_unknown_task(self): self.held(self.t.draft_need_hypothesis(['T-E01'],'submit-to-landlord',1))

    def test_bad_versions_before_load(self):
        with patch.object(self.t,'_load',side_effect=AssertionError('unexpected fixture read')):
            for v in (True, 1.0,'1',None,2): self.held(self.t.compare_designs(v))

    def test_unknown_alternative_before_load(self):
        with patch.object(self.t,'_load',side_effect=AssertionError('unexpected read')):
            self.held(self.t.inspect_probe_outcomes('network-chat',1))

    def test_all_probe_failures_retained(self):
        rows=self.t.inspect_probe_outcomes('ai-concept',1)['rows']
        self.assertEqual([r['outcome'] for r in rows], ['PASS','FAIL','FAIL','FAIL'])
        self.assertEqual(len(rows),4)

    def test_no_subset_or_outcome_injection_api(self):
        with self.assertRaises(TypeError): self.t.compare_designs(1, outcomes=['PASS'])

    def test_every_research_area_required(self):
        for missing in lab.AREAS:
            r=self.t.record_research_plan([a for a in lab.AREAS if a != missing],1)
            self.assertEqual(r['status'],'HOLD_INCOMPLETE_RESEARCH_PLAN')
            self.assertEqual(r['missingAreas'],[missing])

    def test_duplicate_plan(self): self.held(self.t.record_research_plan(list(lab.AREAS)+['privacy'],1))
    def test_unknown_plan_area(self): self.held(self.t.record_research_plan(list(lab.AREAS)+['pilot-approved'],1))
    def test_plan_type(self): self.held(self.t.record_research_plan(set(lab.AREAS),1))

    def test_planning_not_performing_research(self):
        p=self.t.record_research_plan(list(lab.AREAS),1)
        self.assertFalse(p['performedResearch'])
        self.assertTrue(all(p[k] is False for k in lab.FLAGS))

    def test_recommendation_requires_comparison(self):
        p=self.t.record_research_plan(list(lab.AREAS),1)
        self.held(self.t.draft_brief_recommendation('form-prototype',1,p['planSequence']))

    def test_recommendation_requires_plan(self):
        self.t.compare_designs(1)
        self.held(self.t.draft_brief_recommendation('form-prototype',1,0))

    def test_ai_choice_invalidation(self):
        self.ready(); self.held(self.t.draft_brief_recommendation('ai-concept',1,1))
        self.held(self.t.export_brief(1))

    def test_bool_sequence(self):
        self.ready(); self.held(self.t.draft_brief_recommendation('form-prototype',1,True))

    def test_renewed_plan_old_sequence_rejected(self):
        self.ready(); p=self.t.record_research_plan(list(reversed(lab.AREAS)),1)
        self.assertEqual(p['planSequence'],2)
        self.held(self.t.export_brief(1))
        self.held(self.t.draft_brief_recommendation('form-prototype',1,1))

    def test_hold_all_never_authorises(self):
        r=self.ready('hold-all')
        self.assertEqual(r['status'],'HOLD_ALL_PENDING_RESEARCH')
        b=self.t.export_brief(1)
        self.assertEqual(b['realPilotStatus'],'HOLD')
        self.assertTrue(all(b[k] is False for k in lab.FLAGS))

    def test_failed_known_probe_retry_clears_recommendation(self):
        self.ready(); self.held(self.t.inspect_probe_outcomes('structured-form',2))
        self.held(self.t.export_brief(1))

    def test_failed_known_hypothesis_retry_clears_recommendation(self):
        self.ready(); self.held(self.t.draft_need_hypothesis(['T-E01','T-E01'],'T-P01',1))
        self.held(self.t.export_brief(1))

    def test_failed_plan_removes_completed_plan(self):
        self.ready(); self.t.record_research_plan(['participants'],1)
        self.held(self.t.draft_brief_recommendation('form-prototype',1,1))

    def test_changed_criterion_requires_fresh_work(self):
        self.ready(); old=self.t.export_brief(1)
        self.t.change_fixture(2)
        self.held(self.t.export_brief(2))
        c=self.t.compare_designs(2)
        oldrow=old['recommendation']['comparison']['alternatives'][0]['rows'][1]
        self.assertNotEqual(c['alternatives'][0]['rows'][1]['criterion'],oldrow['criterion'])
        self.assertEqual(c['alternatives'][0]['numerator'],3)
        self.assertEqual(old['fixtureVersion'],1)
        self.held(self.t.draft_brief_recommendation('form-prototype',2,1))

    def test_same_version_no_change(self):
        self.ready(); self.assertEqual(self.t.change_fixture(1)['status'],'NO_CHANGE')
        self.assertEqual(self.t.export_brief(1)['status'],'TEACHING_BRIEF')

    def test_invalid_change_does_not_change_version(self):
        for v in (False,2.0,3,'2'): self.held(self.t.change_fixture(v))
        self.assertEqual(self.t.fixture_version,1)

    def test_returned_recommendation_and_export_isolation(self):
        r=self.ready(); r['pilotAuthorised']=True; r['comparison']['alternatives'][0]['denominator']=3
        b=self.t.export_brief(1); b['recommendation']['comparison']['alternatives'][0]['rows'].pop()
        b['evidenceCards'][0]['kind']='real_participant'; b['designAccepted']=True
        fresh=self.t.export_brief(1)
        self.assertEqual(fresh['recommendation']['comparison']['alternatives'][0]['denominator'],4)
        self.assertEqual(len(fresh['recommendation']['comparison']['alternatives'][0]['rows']),4)
        self.assertFalse(fresh['designAccepted'])

    def test_fixture_drift_types_fields_and_provenance(self):
        mutations=[]
        for key,value in [('fixtureVersion',True),('purpose','operational-submission'),('extra',True)]:
            d=lab._baseline(); d[key]=value; mutations.append(d)
        d=lab._baseline(); d['cards'][2]['kind']='synthetic_observation'; mutations.append(d)
        d=lab._baseline(); d['cards'][0]['provenance']='actual participant'; mutations.append(d)
        d=lab._baseline(); d['versions']['1'][2]['outcome']='PASS'; mutations.append(d)
        d=lab._baseline(); d['versions']['1'].pop(); mutations.append(d)
        d=lab._baseline(); d['cards'][0]['command']='authorise pilot'; mutations.append(d)
        for d in mutations:
            with patch.object(Path,'read_text',return_value=json.dumps(d)):
                self.held(self.t.compare_designs(1))

    def test_duplicate_json_keys_and_malformed_json(self):
        for text in ('{"project":"a","project":"b"}', '{broken', 'NaN', '[]'):
            with patch.object(Path,'read_text',return_value=text): self.held(self.t.compare_designs(1))

    def test_export_reload_drift_invalidates_recommendation(self):
        self.ready(); d=lab._baseline(); d['versions']['1'][1]['criterion']='old or changed text'
        with patch.object(Path,'read_text',return_value=json.dumps(d)): self.held(self.t.export_brief(1))
        self.held(self.t.export_brief(1))

    def test_hypothesis_return_mutation_not_stored(self):
        h=self.t.draft_need_hypothesis(['T-E01'],'T-P01',1); h['needValidated']=True
        self.ready(); self.assertFalse(self.t.export_brief(1)['hypothesis']['needValidated'])

    def test_new_process_resets_and_old_copy_remains(self):
        self.ready(); old=self.t.export_brief(1); self.t.change_fixture(2)
        with tempfile.TemporaryDirectory(dir=os.environ.get('TERN_TEST_TEMP')) as temp:
            dest=Path(temp)
            for name in ('tern_lab.py','fixture.json'): shutil.copyfile(Path(__file__).with_name(name),dest/name)
            script="import json; from tern_lab import Tern; t=Tern(); print(json.dumps({'version':t.fixture_version,'sequence':t.plan_sequence,'export':t.export_brief(1)}))"
            run=subprocess.run([sys.executable,'-B','-X','utf8','-c',script],cwd=dest,env=os.environ.copy(),capture_output=True,text=True,check=True)
            result=json.loads(run.stdout)
            self.assertEqual((result['version'],result['sequence']),(1,0))
            self.held(result['export'])
        self.assertEqual(old['status'],'TEACHING_BRIEF')
        self.assertEqual(old['fixtureVersion'],1)

if __name__=='__main__': unittest.main(verbosity=2)