Relay / fictional worked example
Assumptions, ambiguities and decisions
This record shows where the team must avoid silent interpretation. Decisions marked “provisional” would be reviewed when real product evidence arrives.
| ID | Question or conflict | Risk if guessed | Disposition / next step |
|---|---|---|---|
| Q1 | What is a duplicate request? | Discard a valid new issue or create repeated records | Decided for intake: identical (source, external_id) and payload = replay; same key with changed payload = explicit conflict; same text with a new key = distinct request |
| Q2 | Is urgency classification required? | Build and maintain irrelevant feature | Unresolved product hypothesis: optional experiment; not a foundation invariant |
| Q3 | Who may assign another user? | Unauthorised access | Requires security design: identity and tenant permission before public release; demo avoids external access |
| Q4 | Can a resolved request be reopened? | Hidden workflow complexity | Deferred: not required for first slice; no assumption in code |
| Q5 | Is notifying an owner synchronous? | Intake failure if external message service is down | Design decision: notification side effect should not be required to commit intake; detailed delivery semantics before release |
| Q6 | Is there a global request identifier? | Collisions or cross-site exposure | Decided for demo: opaque ID scoped to store; production requires tenant isolation and durable uniqueness |
| Q7 | What does “real time” mean in the queue? | Unnecessary infrastructure | Needs user experiment: define acceptable freshness after workflow trial |
A sample stop rule
If a provider capability appears inconsistent with the agreed contract, the agent must report:
- the exact expected contract;
- observed evidence contradicting it (source, version, failing check);
- the smallest available alternatives;
- the effect of each alternative on architecture and product scope.
The agent may run bounded checks to establish the facts. It may not invent a replacement subsystem or change a public contract without an explicit decision.
The principle in practice
Questions are not merely a form completed before implementation. New ambiguity will arise as the product evolves. It should have somewhere durable to go, a person responsible for the decision and a mechanism for influencing the next phase.