Assumption Fields

Assumption fields are organised across five tabs in the editor: Details, Risk if Wrong, Actions, Notes, and Clarification.

Details

1. Status

• What it’s for: Tracks where the assumption is in its resolution lifecycle.
• Options:

• Target: Every assumption should reach Clarified or Void. An assumption still at Identified at architecture completion is an unresolved gap.

2. Description

• What it’s for: The assumption statement itself — what the team is treating as true.

• What to include:

  • Write as a clear, specific statement: “We assume that…”
  • One assumption per record — if you find yourself writing “and…”, split it into two records.
  • Be precise enough that it is clear what confirmation would look like.

• Example: "We assume that the customer's existing identity provider supports SAML 2.0 federation, allowing the solution to use it for SSO without requiring a new identity platform."

3. Customer Reference

• What it’s for: An optional external reference number or identifier for this assumption in the customer’s own tracking system.

• What to include:

  • If the customer maintains their own RAID log, commercial register, or requirements tracker, record their reference here so the two systems can be cross-referenced.
  • Leave blank if no external reference exists.

• Example: COMP-AS-014

Risk if Wrong

4. Risk if Wrong

• What it’s for: A description of what would happen if this assumption turned out to be false.

• What to include:

  • Describe the impact on the solution, project, cost, or timeline.
  • Be specific: what would need to change, what would be delayed, or what cost would be incurred?
  • This field, combined with the Risk Factor score, allows stakeholders to prioritise which assumptions are most urgent to resolve.

• Example: "If the identity provider does not support SAML 2.0, the solution would require an additional identity brokering layer, adding cost and extending the delivery timeline by an estimated 4–6 weeks."

5. Risk Factor (if wrong)

• What it’s for: A quantified score (0–5) representing how serious the impact would be if this assumption is wrong.
• Scale:

• Use: Sort by Risk Factor to identify the assumptions that need the most urgent attention.

6. Commercial?

• What it’s for: Flags whether this assumption has commercial or contractual significance.
• Set to Yes if: The assumption relates to pricing, service levels, data ownership, licensing, liability, or any other matter that is or could be reflected in a contract.
• Why it matters: Commercial assumptions may need to be tracked in a formal commercial register or reflected in contract schedules. Flagging them here ensures they are not overlooked during commercial and legal review.

7. Area

• What it’s for: Classifies which area of the solution or project this assumption relates to.
• Use: Helps filter and group assumptions when reviewing a particular domain — for example, all data assumptions, all infrastructure assumptions, or all business process assumptions.

8. Building Blocks at Risk (relationship)

• What it’s for: Links the building blocks — Applications, APIs, Services, and other solution components — that depend on this assumption being true.
• What to include:
  • Link any building blocks whose design or specification relies on this assumption.
  • When the assumption is clarified, the clarification record becomes additional specification context for every linked building block.
  • This makes the risk to each component explicit and traceable.

Actions

9. Owner

• What it’s for: The person responsible for driving resolution of this assumption.
• What to include:
  • Name the individual accountable for following up, gathering evidence, or escalating to get a decision.
  • This should be a specific person, not a team or role — someone who can be held accountable.

10. Actions

• What it’s for: A description of the steps being taken to resolve this assumption.
• What to include:
  • What has been done so far and what is planned.
  • Who is being contacted, what evidence is being gathered, what meetings are scheduled.
  • Update this field as the situation progresses.

11. Tasks (relationship)

• What it’s for: Links formal Task items from the project’s action tracker to this assumption.
• Use: If resolution of this assumption requires tracked work items, link them here to maintain visibility alongside the assumption record.

Notes

12. Notes

• What it’s for: A rich-text field for additional narrative context, background information, or meeting notes related to this assumption.
• Use: Record supporting detail that does not fit in the structured fields — email extracts, meeting summaries, supporting references, or historical context about why the assumption was made.

Clarification

13. Clarification

• What it’s for: The resolution of the assumption — what was confirmed, decided, or determined.

• What to include:

  • Record the confirmed fact, the decision that was made, or the reason the assumption is now void.
  • Include the source of the confirmation where relevant (a document, a meeting, a formal decision).
  • This record contributes to the specification of any linked building blocks. When reviewing a building block’s specification, check its linked assumptions and their clarifications — the clarification may contain confirmed requirements that are not recorded elsewhere.

• Set the Status to Clarified (or Void) once this field is completed.

• Example: "Confirmed by the customer's IT Director on 14 March 2026 that the existing Okta instance supports SAML 2.0 federation. Configuration guide provided. See meeting notes in [link]."

14. Date Clarified

• What it’s for: The date on which the clarification was confirmed or the assumption was voided.
• What to include: The date the confirmation was received or the decision was made — not the date the record was updated.

15. Clarified By

• What it’s for: The person who provided or confirmed the clarification.
• What to include: Name the individual whose confirmation resolved the assumption. This establishes accountability and provides a point of contact if the clarification is later questioned.

Other Relationships