diff --git a/CHANGELOG.md b/CHANGELOG.md
index 6aa96f3..7fd8689 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -2,6 +2,7 @@
## Unreleased — initial research scaffold
+- Add eight fictional challenge cards, a contract-question map, a case template, and a partner discovery guide. Keep their unresolved semantics outside the unchanged `0.1.0` executable contract.
- Establish the organisational thesis, claims ledger, and baseline-first research plan.
- Propose a draft `0.1.0` commitment event export with version lineage and occurrence/availability timestamps.
- Add a wholly fictional trajectory, context projection utility, and temporal/semantic validation tests.
diff --git a/README.md b/README.md
index 576563f..8b385b0 100644
--- a/README.md
+++ b/README.md
@@ -68,6 +68,8 @@ A simple model that wins is a successful research result. A shared model valid f
| [Foundations](docs/foundations.md) | The organisation, human agency, and learning from priors |
| [Research plan](docs/research-plan.md) | Hypotheses, comparisons, evaluation, and stop conditions |
| [Data contract](docs/data-contract.md) | What to collect, label, connect, and keep out |
+| [Fictional challenge set](examples/challenge-set/README.md) | Eight difficult or contrasting cases that question the contract and its scope |
+| [Partner discovery guide](docs/partner-discovery.md) | A first conversation that lets partners introduce their own distinctions |
| [Application integration](docs/application-integration.md) | How apps contribute to the Organisation Core |
| [First 90 days](docs/first-90-days.md) | A bounded starting project and collaboration questions |
| [Reading list](docs/reading-list.md) | Intellectual lineage and the limits of the evidence |
@@ -86,6 +88,8 @@ python3 -m venv .venv
This validates the draft event contract and constructs the context available at a historical prediction cutoff. It demonstrates exclusion of late-arriving evidence, future actions, and outcome assessments from predictor inputs. It does **not** train a model or establish that a dataset is suitable for research. See [the example walkthrough](examples/README.md).
+For discussion before collecting data, use the [eight fictional challenge cards](examples/challenge-set/README.md). They preserve unresolved interpretations and deliberately include work that may not fit the commitment abstraction. They are authored scenarios, not labelled training data; the current schema remains unchanged.
+
The validation command reports **11 valid fictional events**. The Tuesday-noon snapshot contains **e01, e02, and e03**: the accepted promise, a reported delay, and a proposed response. An observation made earlier but received Wednesday is correctly excluded. The test suite checks these boundaries and the preservation of both commitment versions.
## Project status
diff --git a/docs/first-90-days.md b/docs/first-90-days.md
index 56e63ff..5b1a4ac 100644
--- a/docs/first-90-days.md
+++ b/docs/first-90-days.md
@@ -13,6 +13,8 @@ Sequence/graph models and JEPA follow only if these results justify them. Long c
## Initial work packages
+The [fictional challenge set](../examples/challenge-set/README.md) and [partner discovery guide](partner-discovery.md) provide starting material for the first two work packages. Gather participants' own accounts before showing the cards; no case constitutes a partner finding or a training label.
+
1. **Target definition:** choose a recurring promise, specify fulfilment and observation, and identify where revisions make labels ambiguous.
2. **Contract review:** challenge the action vocabulary, version lineage, beneficiary role, late evidence, and missing-data semantics with fictional counterexamples.
3. **Measurement adapter:** export one prospective trajectory across two surfaces, preserving authority and provenance.
diff --git a/docs/partner-discovery.md b/docs/partner-discovery.md
new file mode 100644
index 0000000..d0e5fab
--- /dev/null
+++ b/docs/partner-discovery.md
@@ -0,0 +1,53 @@
+# Partner discovery with fictional cases
+
+Purpose: discover whether the problem, unit of analysis, and outcome definitions fit a partner's work before proposing a dataset. This is a conversation guide, not a validated interview instrument or a request for data access.
+
+The [challenge set](../examples/challenge-set/README.md) contains eight wholly fictional discussion cards. It is deliberately small and incomplete. No partner findings have been collected through this guide yet.
+
+## A first conversation: about 40 minutes
+
+**First 10 minutes — their work before our vocabulary.** Ask: “Can you describe a recurring piece of work where several people depend on what happens next?” Invite a fictional or suitably general account. Let them name the roles, purpose, and expectations. Follow with “How do you know it went well?” and “What happens when circumstances change?” Avoid introducing commitment, failure, JEPA, or our action categories as required answers.
+
+**Next 10 minutes — establish one decision point.** Ask what was known at that moment, what was missing, who could act, and where evidence would appear later. Distinguish the date something happened from when the relevant person or system learned of it. Ask what useful work never enters the records and what would be burdensome to capture. A participant should not need to disclose documents or names.
+
+**Next 15 minutes — use two or three cards.** Choose cases that illuminate the participant's account, including a routine or poor-fit case where relevant. Show the decision point first; keep the later account and maintainer discussion collapsed. Ask for an interpretation, then reveal what happened and ask what changed. Do not use the maintainer notes to mark answers correct. Ask which details feel implausible, which cases are missing, and whether the underlying abstraction helps.
+
+**Final 5 minutes — agree one small follow-up.** It could be a new fictional case, a target-definition review, or a diagram of where evidence lives. Agree what may be retained and shared. There is no requirement to offer data, endorse the project, or join a pilot.
+
+## Preserve disagreement and the source of an idea
+
+If several people attend, invite independent initial interpretations before group discussion when practical. Record differences rather than forcing consensus. Distinguish an idea the participant introduced unaided from an answer prompted by a card or by the facilitator. The latter may be useful, but it is weaker evidence that the issue was salient without prompting.
+
+Use these prompts sparingly:
+
+- “Who would describe this differently?”
+- “What evidence would change that interpretation?”
+- “What can the existing systems already do well?”
+- “Is this a data-model problem, a working-practice problem, or something we should leave outside the project?”
+- “What would make this effort cost more than it helps?”
+
+## A lightweight note template
+
+This is a blank template, not an example of a completed interview. Keep working notes outside the public repository. Retain only what the participant agrees to; do not record the session by default.
+
+| Field | What to record |
+| --- | --- |
+| Agreed purpose and handling | What may be noted, retained, abstracted, and shared; no implied research/data permission |
+| Work in the participant's terms | Their unit of work and desired result, before using project vocabulary |
+| Unaided observations | Issues and distinctions raised before showing any card |
+| Cutoff and visibility | What information existed and when the relevant people/system could access it |
+| Cards and order shown | Stable IDs and whether the later account or maintainer notes had been revealed |
+| Interpretations | Distinct accounts, including unresolved disagreements and rejection of the framing |
+| Missing evidence and burden | What would distinguish the accounts and the cost of observing it |
+| Candidate consequence | A question, target, procedure, contract change, or exclusion; mark as tentative |
+| Follow-up | A bounded artefact, willing owner if agreed, and what may be made public |
+
+Do not copy personal identifiers, confidential examples, private quotes, or organisational records into public issues. Permission to have a conversation is not permission to publish its contents or train on them. Follow the repository's [data stewardship proposal](data-contract.md#data-stewardship).
+
+## Turn discovery into a reviewable change
+
+Start with a finding candidate, not a generator: describe the abstract ambiguity, plausible interpretations, and evidence needed. Keep a single anecdote distinct from a recurring pattern; record contrary accounts and unknowns. Do not report interview counts as prevalence in organisations or assert saturation from this small exercise.
+
+If an issue can be illustrated safely, write a new fictional card and ask whether it preserves the important distinction. A public issue can then propose one of four outcomes: clarify the target; improve observation/adjudication; extend the contract with tests; or exclude the case from the current prediction task. Leave the choice open when evidence is insufficient.
+
+Bulk synthetic generation becomes useful when a reviewed question calls for controlled variation or engineering scale tests. It should encode declared, contestable assumptions. It cannot supply evidence that those assumptions describe organisations or that a model trained on them will transfer to partner data.
diff --git a/examples/README.md b/examples/README.md
index c6cc2ec..7398141 100644
--- a/examples/README.md
+++ b/examples/README.md
@@ -2,6 +2,8 @@
Every entity, event, source, and probability in `fictional-trajectory.jsonl` is invented. This is an executable specification example, not a training dataset or benchmark. No model generated the example's probability.
+For cases that challenge the contract and its scope, see the [fictional challenge set](challenge-set/README.md). Those discussion cards include unresolved semantics and are not JSONL fixtures. Start partner conversations with the [discovery guide](../docs/partner-discovery.md).
+
The fictional team promises an integration by Friday 9 January. It later agrees a Monday 12 January deadline with the customer. Friday's original promise is assessed as not met; Monday's revised promise is assessed as met. Both assessments remain attached to their own versions.
| Event | Meaning |
diff --git a/examples/challenge-set/C01-delivered-but-rejected.md b/examples/challenge-set/C01-delivered-but-rejected.md
new file mode 100644
index 0000000..7d53365
--- /dev/null
+++ b/examples/challenge-set/C01-delivered-but-rejected.md
@@ -0,0 +1,33 @@
+# C01 — Delivered on time, rejected by the beneficiary
+
+Wholly fictional discussion case. No canonical outcome label. Facilitators should reveal the later account only after discussing the decision point.
+
+## At the decision point
+
+A service team accepts a promise to provide a customer with a weekly export by Friday at 17:00. The recorded criteria specify the file format, required columns, and delivery location. The customer intends to use the export in an existing reconciliation process; no representative sample or compatibility check was agreed.
+
+On Thursday at 12:00, the delivery owner knows the file passes the recorded format checks. The customer's operations lead has asked whether it will work in their process, but that question has no recorded answer. The owner must decide whether to investigate compatibility before delivery.
+
+**Before revealing the outcome:** What has actually been promised? What evidence is available for a forecast, and whose interpretation matters?
+
+
+Reveal the later account
+
+The file arrives Friday at 16:30 and passes every recorded check. On Monday the customer rejects it: the values use a convention their reconciliation process cannot interpret. Delivery records completion; customer operations records that the expected benefit was not received. Nobody disputes when the file arrived.
+
+
+
+## Questions for the participant
+
+- Would you call this fulfilment, failure, or a badly formed promise? What would distinguish those accounts?
+- Does the beneficiary's rejection identify an existing obligation or introduce a new requirement?
+- What small clarification at the start would have prevented the ambiguity, and who could authorise it?
+
+
+Maintainer discussion — provisional, not an answer key
+
+Under a narrow interpretation, the written criteria were met and the realised value was poor. Under a broader accepted understanding, compatibility was part of the promise and fulfilment is disputed. Preserve both accounts until the scope is resolved; do not silently rewrite the original criteria or make satisfaction automatically determine every label.
+
+The draft can store criteria, observations, and a disputed assessment. It lacks structured beneficiary acceptance and realised-value dimensions. A candidate discovery is whether these require separate targets, better acceptance procedures, or both. Ask for the agreed scope, a sample agreed before the deadline, and evidence of who could accept it. This case supplies none of that missing evidence.
+
+
diff --git a/examples/challenge-set/C02-responsible-cancellation.md b/examples/challenge-set/C02-responsible-cancellation.md
new file mode 100644
index 0000000..6a2f338
--- /dev/null
+++ b/examples/challenge-set/C02-responsible-cancellation.md
@@ -0,0 +1,35 @@
+# C02 — A responsible cancellation
+
+Wholly fictional discussion case. No canonical outcome label.
+
+## At the decision point
+
+A facilities team accepts a promise to equip a training room by Day 20. The authorised scope includes furniture, equipment, and a working demonstration. By Day 8, equipment has been ordered but installation has not begun.
+
+On Day 9, the organisation decides to leave the building. The requester and facilities owner know this. They can continue installation, seek permission to stop, or negotiate a different use for the equipment. Some purchases are refundable; others have already incurred costs.
+
+**Before revealing the outcome:** Which obligation still matters, and who may release the team from it?
+
+
+Reveal the later account
+
+On Day 10, the authorised sponsor and requester agree to cancel the room setup. The team returns refundable equipment and documents the remaining costs. No room is equipped by Day 20. The requester reports that a usable room in the old building would now have no value. The scenario does not establish exactly what would have been spent had work continued.
+
+
+
+## Questions for the participant
+
+- Which record distinguishes a legitimate release from a team quietly abandoning a promise?
+- What obligations survive cancellation, such as handling costs or informing dependent teams?
+- How would you compare responsible stopping with unnecessary cancellation without rewarding either automatically?
+
+
+Maintainer discussion — provisional, not an answer key
+
+The original physical deliverable was not produced. That fact alone does not establish a poor organisational decision. A completion-only target and a decision-quality evaluation answer different questions. Cancellation also does not erase the original promise or guarantee the change was wise.
+
+The draft can describe a `revise_stop` action but does not provide a ratified withdrawal state or a release-of-obligations contract. An abandoned action is not a cancelled commitment. Rewriting the intent of a later version may hide rather than solve this distinction.
+
+Keep this trajectory outside the initial binary benchmark until its target policy is explicit. Candidate needs include authority, beneficiary agreement, residual obligations, and observed costs. Claims about avoided costs would require additional assumptions or a separate comparison. A partner might instead recommend excluding this commitment family altogether.
+
+
diff --git a/examples/challenge-set/C03-competing-commitments.md b/examples/challenge-set/C03-competing-commitments.md
new file mode 100644
index 0000000..c49fe15
--- /dev/null
+++ b/examples/challenge-set/C03-competing-commitments.md
@@ -0,0 +1,35 @@
+# C03 — Two promises, one shared resource
+
+Wholly fictional discussion case. No canonical outcome label.
+
+## At the decision point
+
+Two teams accept separate customer onboarding promises, A and B, both due Friday. Each requires one full day of the same specialist before the customer can verify the result. The specialist has one day available that week. Neither customer agreed to a priority rule.
+
+At Tuesday noon, each team can see its own promise and a reference to the specialist. Both believe a day is reserved. The organisation's allocation record, available to a coordinator, shows only one reservation slot. That discrepancy has not reached either delivery team. An organisational predictor would need a declared access scope: what one team knows is not automatically what the prediction system knows.
+
+**Before revealing the outcome:** What would you need to know to forecast these promises together? Who can resolve the conflict?
+
+
+Reveal the later account
+
+On Wednesday, a coordinator discovers the double reservation. Under an explicit escalation mandate, the organisation allocates the specialist to A and agrees a Monday revision for B with its customer. A is fulfilled Friday. B misses its original deadline and is fulfilled Monday. The customer affected by B incurs disruption that the scenario does not quantify.
+
+
+
+## Questions for the participant
+
+- Where should evidence of the shared constraint have appeared, and when was it available to whom?
+- Does A's success demonstrate a better team or simply the allocation decision?
+- What would make the priority decision acceptable to both beneficiaries?
+
+
+Maintainer discussion — provisional, not an answer key
+
+Separate labels can describe fulfilment of the respective versions, but independent feature rows may conceal the shared cause. A resource allocation might improve one prediction target while worsening another. This case cannot identify the best priority policy.
+
+The draft supports multiple commitments and opaque dependency references. It does not structure capacity, reservation conflicts, access scope, or priority authority. Free-text descriptions would not automatically enable graph inference about contention.
+
+Candidate evidence includes capacity with units and effective dates, reservation history, each promise's consequences, and the authority to trade them off. Related trajectories may need to stay together when designing evaluation splits. Discover whether the partner's records can support that grouping before treating each promise as an independent example.
+
+
diff --git a/examples/challenge-set/C04-late-evidence.md b/examples/challenge-set/C04-late-evidence.md
new file mode 100644
index 0000000..6b4e654
--- /dev/null
+++ b/examples/challenge-set/C04-late-evidence.md
@@ -0,0 +1,37 @@
+# C04 — Late evidence changes the assessment
+
+Wholly fictional discussion case. No canonical outcome label.
+
+## At the decision point
+
+A storage service commits to keeping a shipment within an agreed temperature range through Friday at 17:00. Its acceptance criteria identify the monitoring interval and the measurement source.
+
+At Thursday noon, all readings available to the prediction system are within range. A sensor has recorded additional readings locally, but those readings have not been transmitted. There is no basis at that cutoff to assert what Friday's measurements will show.
+
+**Before revealing the outcome:** Which clocks must be preserved so a future training run can reproduce Thursday's information?
+
+
+Reveal the later account
+
+Friday at 17:20, the monitoring service reports a breach during the agreed interval. An assessor records `not_met` with that evidence. On Tuesday, a reviewed correction shows the transmitted series used an incorrect conversion. The corrected source readings support a later `met` assessment against the same original criteria. The original report and both assessments remain in the history.
+
+The corrected readings concern Friday, but their corrected interpretation was first available Tuesday. Moving that knowledge back to Friday would change what the earlier predictor could have known.
+
+
+
+## Questions for the participant
+
+- What evidence permits the second assessment to supersede the first?
+- What label would a training run on Monday have had access to? What changes for a later run?
+- Would repeated evidence corrections reveal a delivery problem, a measurement problem, or both?
+
+
+Maintainer discussion — provisional, not an answer key
+
+The draft's occurrence and availability timestamps support late evidence; the context utility excludes it before availability. The draft also allows multiple assessments of one version. It has no typed correction link, adjudication rule, or label-selection implementation.
+
+Selecting the last event by timestamp is not a sufficient governance rule. A later assertion can also be wrong or unauthorised. Preserve assessment provenance and distinguish a historical replay using labels then available from an evaluation using subsequently adjudicated outcomes. Both can be useful, but must be declared separately.
+
+Candidate evidence includes the correction's basis, authorised adjudication, and immutable dataset manifests. This story does not establish that any real measurement source has those properties.
+
+
diff --git a/examples/challenge-set/C05-forecast-and-intervention.md b/examples/challenge-set/C05-forecast-and-intervention.md
new file mode 100644
index 0000000..ceb0c94
--- /dev/null
+++ b/examples/challenge-set/C05-forecast-and-intervention.md
@@ -0,0 +1,37 @@
+# C05 — A warning is followed by successful intervention
+
+Wholly fictional discussion case. No canonical outcome label or causal conclusion. No model was run to produce the warning in this story.
+
+## At the decision point
+
+A team has promised a customer a working migration by Friday. By Wednesday at 09:00, validation is behind schedule. A forecasting service would flag the promise as at risk using only the history then available. The owner could see the warning, challenge it, seek more evidence, or authorise extra validation capacity.
+
+At this cutoff, no extra capacity has been authorised or delivered. A proposed action is available as an option; its later execution is not yet a known input.
+
+**Before revealing the outcome:** What would you need to record to distinguish a forecast from advice that influenced the decision?
+
+
+Reveal the later account
+
+The owner sees the warning, asks a specialist to check its reasoning, and authorises extra capacity at 11:00. Work begins that afternoon. The customer verifies fulfilment before Friday's deadline. Another team's non-urgent work was deferred to provide the capacity.
+
+The owner says the warning prompted the escalation. There is no observed version of this same case in which the warning was hidden or the intervention withheld.
+
+
+
+## Questions for the participant
+
+- Is the warning now a false alarm, a useful warning, or still unresolved? Which target and evidence would decide?
+- What else might explain the successful delivery?
+- How would you assess intervention cost, displaced work, and the owner's understanding?
+
+
+Maintainer discussion — provisional, not an answer key
+
+The observed commitment can be assessed as fulfilled if evidence supports its criteria. That does not prove the warning was accurate, inaccurate in a useful sense, or causally effective. A probabilistic forecast also cannot be judged by one realised outcome alone.
+
+The draft can carry a forecast and subsequent actions, but `exposure: advice` does not establish who actually saw it, when, or what they understood. Actual exposure and action-selection links remain proposed extensions. Realised future actions must not become known inputs to the Wednesday forecast.
+
+Candidate needs include a clearly specified forecast policy/target, exposure receipts, the considered alternatives, costs, and a prospective comparison. Ask whether a shadow phase and later controlled advice study are feasible. Do not treat a participant's attribution, although valuable evidence, as proof of the unobserved counterfactual.
+
+
diff --git a/examples/challenge-set/C06-disputed-meaning.md b/examples/challenge-set/C06-disputed-meaning.md
new file mode 100644
index 0000000..df926c7
--- /dev/null
+++ b/examples/challenge-set/C06-disputed-meaning.md
@@ -0,0 +1,37 @@
+# C06 — The same words, different promises
+
+Wholly fictional discussion case. No canonical outcome label.
+
+## At the decision point
+
+A meeting ends with the phrase “ready for the launch on Friday.” A project application records version 1 as accepted, with the criterion “launch ready” and a reference to a programme mandate.
+
+The engineering lead interprets this as a deployable internal build. The customer-facing lead interprets it as a service external customers can use with support in place. A regional representative believes the meeting agreed only to investigate feasibility. None of those interpretations is recorded as a ratified revision.
+
+At Monday noon, the application shows one accepted commitment. The participants still hold these different understandings. A forecast based on the record has no agreed operational definition of fulfilment.
+
+**Before revealing the outcome:** Is there one commitment here? What would establish its meaning and authority?
+
+
+Reveal the later account
+
+On Friday, engineering demonstrates the internal build. The customer-facing lead reports non-fulfilment because external onboarding is unavailable. The regional representative disputes that a delivery promise was authorised at all. Each can point to a different part of the meeting discussion. No agreed adjudication has taken place.
+
+
+
+## Questions for the participant
+
+- Which evidence could resolve meaning, and which could establish authority? Are those the same question?
+- How could participants have exposed disagreement without requiring another approval meeting for every task?
+- What would an app need to preserve beyond the single accepted text?
+
+
+Maintainer discussion — provisional, not an answer key
+
+Do not turn majority agreement, an application status, or the most senior participant's recollection into an automatic label. Preserve the dispute. Clarifying the promise later must not make a specific interpretation appear to have been shared earlier.
+
+The draft checks that an authority reference exists, not that it confers valid authority. It can record conflicting observations and a disputed outcome. It cannot establish legitimate ratification, shared understanding, or a binding interpretation from those strings.
+
+This may be an observation and deliberation design problem before it is a modelling problem. Candidate evidence includes the mandate's actual scope, independent participant restatements, accepted operational criteria, and an adjudication process. A partner may conclude there was no valid bounded commitment to predict at the supposed cutoff.
+
+
diff --git a/examples/challenge-set/C07-routine-fulfilment.md b/examples/challenge-set/C07-routine-fulfilment.md
new file mode 100644
index 0000000..329cae9
--- /dev/null
+++ b/examples/challenge-set/C07-routine-fulfilment.md
@@ -0,0 +1,35 @@
+# C07 — Routine fulfilment without an escalation
+
+Wholly fictional discussion case. No canonical outcome label. This provides a contrast to the disruption-heavy cards; it does not imply that routine fulfilment is common or rare.
+
+## At the decision point
+
+A reporting team accepts a recurring promise to deliver an agreed monthly report by Day 5 at 12:00. Criteria and beneficiary acceptance are well understood for this fictional instance. On Day 3, source data has arrived and existing capacity is sufficient.
+
+The owner checks the evidence and explicitly reaffirms the plan. The team continues the ordinary work. It neither escalates nor seeks a special intervention. Another application has no action log because the work happens in an existing reporting tool.
+
+**Before revealing the outcome:** What would distinguish an uneventful trajectory from incomplete capture?
+
+
+Reveal the later account
+
+The report arrives on Day 5 at 10:00. The beneficiary verifies the agreed contents and confirms acceptance before the deadline. An assessment after the deadline has that supporting evidence. There are few entries in the project application, but the reporting tool retains preparation and delivery records.
+
+
+
+## Questions for the participant
+
+- Which records were necessary to make and assess this promise well?
+- What would be lost by requiring every routine action to be copied into a new system?
+- What distinguishes an explicit decision to continue from simply having no record?
+
+
+Maintainer discussion — provisional, not an answer key
+
+Low visible activity is not proof that no work occurred or that intervention was needed. Richer logging is also not automatically evidence of better practice. Comparing these cases with heavily monitored troubled cases can entangle observation behaviour and underlying risk.
+
+The draft can carry a known `reaffirm_defer` action and a supported outcome assessment. It does not model the completeness of each source's action capture. Its envelope records provenance references, but does not fetch or certify the underlying records.
+
+Candidate discovery concerns the minimum useful observation plan and whether references to existing evidence suffice. Keep collection burden visible. A partner who can reliably assess this commitment with three observations may be offering a better starting pilot than one requiring exhaustive event capture.
+
+
diff --git a/examples/challenge-set/C08-work-without-a-promise.md b/examples/challenge-set/C08-work-without-a-promise.md
new file mode 100644
index 0000000..880e443
--- /dev/null
+++ b/examples/challenge-set/C08-work-without-a-promise.md
@@ -0,0 +1,35 @@
+# C08 — Valuable work without a bounded promise
+
+Wholly fictional discussion case. No canonical outcome label. The commitment framing itself is open to challenge.
+
+## At the decision point
+
+A colleague has offered to help new team members find their way through unfamiliar work. There is no named beneficiary list, fixed deliverable, acceptance test, or completion date. Support is voluntary and changes as people join and learn. Some assistance is a quiet conversation rather than a recorded event.
+
+At the start of a month, a manager considers turning the activity into a commitment with a target number of answered questions. The colleague worries that this would change the work: answering quickly might displace helping someone develop their own judgment.
+
+**Before revealing the later account:** What, if anything, should be represented as a commitment here?
+
+
+Reveal the later account
+
+At the end of the month, participants give different accounts. Some describe becoming more confident; others still need help. There is no agreed before/after measure and no basis for attributing changes to one person's support. The proposed question-count target was never accepted.
+
+
+
+## Questions for the participant
+
+- Is this a standing responsibility, an informal relationship, an intention, or a commitment? Which distinction changes a decision?
+- Would measurement improve the work or alter it in an undesirable way?
+- What should remain outside organisational prediction and individual evaluation?
+
+
+Maintainer discussion — provisional, not an answer key
+
+The current bounded-deadline target does not fit this account. Supplying invented criteria, authority, or dates just to satisfy the schema would manufacture the phenomenon we hoped to understand. It would also risk turning personal development into an employee performance measure.
+
+The draft requires an accepted commitment version for every exported event. It cannot represent this activity faithfully without deciding on a different unit or excluding it. That is a scope boundary, not automatically a schema defect.
+
+Candidate outcomes of discovery include preserving qualitative context outside the prediction dataset, researching standing obligations separately, or leaving the activity uninstrumented. The participant need not accept the proposition that all organisational value should be expressed as a bounded promise. Ask what would be lost, as well as what might be learned, by doing so.
+
+
diff --git a/examples/challenge-set/README.md b/examples/challenge-set/README.md
new file mode 100644
index 0000000..15ae935
--- /dev/null
+++ b/examples/challenge-set/README.md
@@ -0,0 +1,50 @@
+# Fictional commitment challenge set
+
+Eight authored scenarios for questioning the commitment abstraction, outcome definitions, and draft data contract. Every event, role, and organisation is invented. There are no partner observations or model-generated forecasts behind these stories.
+
+These are discussion cards, **not training examples, frequency estimates, or a benchmark**. They deliberately include unresolved meanings that the current event contract cannot express fully. No canonical labels are assigned. The number of cases in any category says nothing about how often it occurs in practice.
+
+## Start with the participant's experience
+
+Use the [partner discovery guide](../../docs/partner-discovery.md) before showing the cards. Ask the participant to describe a familiar piece of work in their own vocabulary. Then select two or three relevant cards rather than working through the whole set.
+
+Each card separates what was known at a decision point from what happened later. Pause before revealing the later account. The maintainer discussion is a provisional interpretation, not an answer key. Someone who rejects the scenario or the commitment framing may be exposing the most valuable gap.
+
+| ID | Card | Assumption to challenge |
+| --- | --- | --- |
+| C01 | [Delivered on time, rejected by the beneficiary](C01-delivered-but-rejected.md) | Recorded delivery and valuable fulfilment mean the same thing |
+| C02 | [A responsible cancellation](C02-responsible-cancellation.md) | Stopping a commitment is always failure |
+| C03 | [Two promises, one shared resource](C03-competing-commitments.md) | Commitment outcomes can be understood independently |
+| C04 | [Late evidence changes the assessment](C04-late-evidence.md) | The latest account was available to earlier decisions |
+| C05 | [A warning is followed by successful intervention](C05-forecast-and-intervention.md) | Averted failure proves either model error or model value |
+| C06 | [The same words, different promises](C06-disputed-meaning.md) | One accepted record establishes shared meaning and legitimate authority |
+| C07 | [Routine fulfilment without an escalation](C07-routine-fulfilment.md) | More recorded activity implies better outcomes |
+| C08 | [Valuable work without a bounded promise](C08-work-without-a-promise.md) | Every useful contribution should become a deadline commitment |
+
+## Contract questions to carry into discovery
+
+The [draft 0.1.0 contract](../../docs/data-contract.md) and current validator already preserve accepted versions, occurrence/availability times, and distinct action stages. Free text can describe more than the structured fields can represent. Being able to put a story in a description is not the same as having interoperable semantics for it.
+
+| Cases | What the draft can express | Unresolved research/design question |
+| --- | --- | --- |
+| C01, C06 | Written criteria, authority references, observations, disputed assessments | Who interprets criteria, which beneficiaries must accept, and how disagreements are adjudicated |
+| C02 | A proposal/action to stop and a later learning record | Ratified withdrawal, release of obligations, and effects on beneficiaries |
+| C03 | Multiple commitments and dependency references | Shared capacity with units/time, resource contention, and connected evaluation groups |
+| C04 | Late observations and multiple assessment events | Which assessment supersedes another, why, and which label was available at each training cutoff |
+| C05 | Forecasts and subsequent action records | Actual advice exposure, action selection, spillovers, and causal identification |
+| C07 | Known reaffirm/defer actions and supported outcome assessments | How to distinguish low intervention need, missing capture, and unrecorded work |
+| C08 | Narrative observations linked to an accepted commitment, if one exists | Whether a bounded commitment is the appropriate unit at all |
+
+This table records **candidate gaps**, not approved requirements or findings about real organisations. Current version remains `0.1.0`; these cards do not change the schema or validator. No card is represented as a schema-valid JSONL fixture. The original [executable trajectory](../README.md) remains the implementation example.
+
+## From a case to a useful discovery
+
+Record the interpretation, an alternative interpretation, the evidence needed to distinguish them, and the consequence for the research. A consequence may be a field change, an observation procedure, a separate target, or an explicit exclusion from scope. Do not assume every ambiguity needs another field.
+
+Use the [case template](TEMPLATE.md) for a new fictional counterexample. Stable IDs make discussion traceable; they do not make interpretations permanent. Keep open questions open until a documented decision changes their status. Partner-informed revisions need permission and enough abstraction to avoid identifying the underlying people or organisation.
+
+## When more synthetic data becomes useful
+
+After reviewing these questions with practitioners, propose generators for specific engineering purposes: timestamp boundary checks, missing-event handling, workload scale, or recovery from conflicting observations. Name the assumed mechanism, vary it deliberately, and document how it could be wrong. Keep generated artefacts separate from partner observations.
+
+Do not select a model architecture because it performs well on labels produced by that same generator. Advancing to a generator should follow a concrete question and reviewed semantics; it does not follow automatically from finishing these eight cards.
diff --git a/examples/challenge-set/TEMPLATE.md b/examples/challenge-set/TEMPLATE.md
new file mode 100644
index 0000000..ce105fb
--- /dev/null
+++ b/examples/challenge-set/TEMPLATE.md
@@ -0,0 +1,29 @@
+# CXX — Short scenario title
+
+Wholly fictional discussion case. No canonical outcome label. Describe an invented situation rather than anonymising a recognisable private account. If practitioners informed the design, document permission and the abstract lesson separately before publishing.
+
+## At the decision point
+
+State the work, relevant roles, what was accepted (or disputed), criteria, deadline if any, and authority if known. Name a prediction/decision cutoff. Separate information available then from information held elsewhere or learned later. Leave missing facts explicitly missing.
+
+**Before revealing the outcome:** Ask an open question without suggesting the desired interpretation.
+
+
+Reveal the later account
+
+Describe observations and actions after the cutoff. Distinguish delivery, assessment, revision, and claimed benefit. Include occurrence and availability differences where relevant. Do not invent a counterfactual outcome or a model probability to complete the story.
+
+
+
+## Questions for the participant
+
+- What interpretations are possible?
+- What evidence would distinguish them?
+- What does this case omit or misrepresent about work like this?
+
+
+Maintainer discussion — provisional, not an answer key
+
+Name the assumption being tested, plausible competing accounts, and the minimum evidence needed. Identify what draft 0.1.0 can carry, what its validator actually checks, and what remains outside the contract. State any target that cannot yet be assigned. Consider an observation procedure or exclusion from scope as alternatives to schema expansion.
+
+