DP-014

Assumption Externalisation and Challenge

Research and design decisions are shaped by assumptions that often remain implicit. Externalise those premises in an assumption register, distinguish evidence from defaults and values, and challenge each assumption through alternative perspectives, counterexamples and consequence testing. Record the risks attached to retaining or revising it. The aim is not to eliminate assumptions, but to make them inspectable and accountable so a named decision maker can retain, revise, test or discard them deliberately.

Source manuscript

When this helps

Editorial synthesis grounded in the source pattern. Research, design and planning situations in which implicit premises may constrain interpretation, creativity, inclusion or risk management.

Academics frequently bring implicit assumptions into research and design work without recognising them. Prior experience, disciplinary norms and habitual practices shape problem framing, data interpretation and proposed solutions. When these assumptions remain unexamined, they constrain creativity, reinforce bias and limit the applicability of outcomes.

Pattern response

Editorial synthesis grounded in the source response. Externalise material assumptions in a register that distinguishes evidence, interpretation, values and defaults. Challenge them through alternative perspectives, counterexamples and consequence testing, and record the risks attached to retaining or changing each one. A named decision-maker then retains, revises, tests or discards the assumption deliberately.

  • An assumption register distinguishing evidence, interpretation, values and defaults.
  • Alternative framings, counterexamples and consequence or risk tests for material assumptions.
  • An accountable decision to retain, revise, test or discard each significant assumption.

Workflow at a glance

DP-014 | Assumption Testing Portrait workflow diagram for Challenging and Identifying Own Assumptions DP-014 | Assumption Testing
Canonical workflow · DP-014Assumption Externalisation and Challenge
  1. 01

    Externalise the problem framing

    An accountable academic initiates, interprets, or approves this stage; automation remains bounded by the listed modules.

    MOD-001 · MOD-040
  2. 02

    Identify assumptions

    An accountable academic initiates, interprets, or approves this stage; automation remains bounded by the listed modules.

    MOD-021 · MOD-017
  3. 03

    Challenge from alternatives

    An accountable academic initiates, interprets, or approves this stage; automation remains bounded by the listed modules.

    MOD-031 · MOD-022 · MOD-036
  4. 04

    Test consequences and scenarios

    An accountable academic initiates, interprets, or approves this stage; automation remains bounded by the listed modules.

    MOD-020 · MOD-042
  5. 05

    Retain, revise, or discard

    An accountable academic initiates, interprets, or approves this stage; automation remains bounded by the listed modules.

    MOD-044 · MOD-037

Human checkpoints

People define purpose and boundaries, supply or authorise source material, inspect intermediate representations, resolve ambiguity, approve consequential outputs, correct errors, and remain accountable for scholarly, pedagogical, legal, or organisational decisions. A generated recommendation or draft is not an approval decision.

Risks and misuse

Source-stated improvement concerns

  • Assumption identification risks becoming performative unless followed by substantive changes in design or research direction.
  • Excessive interrogation may impede progress, as some assumptions must be provisionally accepted to enable action.
  • Over reliance on AI may produce superficial identification without sufficient contextual grounding.
  • Generating extensive lists of assumptions introduces environmental and temporal costs if not meaningfully applied.

Inferred workflow risks

  • Inferred: unstated constraints.
  • Inferred: scope drift.
  • Inferred: ambiguous success conditions.
  • Inferred: context drift.
  • Inferred: false continuity.
  • Inferred: overconfident response.
  • Inferred: unauthorised action.
  • Inferred: invented assumptions.

Use this pattern

Begin with the recurring problem and the authorised inputs. Follow the workflow in order, keep intermediate outputs inspectable and retain the named human decisions.

  • Minimum viable implementation: a documented human procedure using the ordered modules: Workflow Briefing and Context Definition → Conversational Interaction → Assumption Identification → Argument and Concept Analysis → Question and Probe Generation → Perspective Simulation → Dialogue and Turn Management → Constraint Checking → Output Quality Evaluation → Human Review and Approval → Record Storage.
  • Robust implementation: add explicit schemas, source identifiers, access controls, logging, exception queues, independent evaluation, backups, and named approval owners.
  • Low-code implementation: use forms and a workflow orchestrator to connect bounded services, with approval gates before external communication or state changes.
  • Local or privacy-preserving implementation: keep sensitive artefacts in controlled storage and prefer local extraction, transcription, search, or model execution where capability and governance permit.
  • Speculative implementation: more autonomous coordination may be explored only with constrained tools, stop conditions, audit logs, and human authority; it is not implied by the source pattern.

Reusable modules

View in Atlas →

Technical and provenance detail

Data and information flow

Inputs may include request, context, constraints, user message, dialogue state, available tools or sources, problem framing, argument, plan, idea or text, analysis question, idea or claim, inquiry stance, dialogue history, issue, perspective definitions, interaction rules, roles, candidate output, constraint set, output, criteria, source evidence, candidate output or action, evidence, review criteria, artefact or record, metadata, retention rule. The stage sequence transforms, analyses, enriches, retrieves, generates, coordinates, stores, or outputs information according to each linked module contract. Outputs may include approved workflow brief, response, state update, action or question, assumption register, support status, test questions, argument map, conceptual issues, identified tensions, questions, follow-up probes, rationale, perspective-specific responses, tensions, shared assumptions, ordered dialogue, state updates, termination signal, pass/fail findings, exceptions, unresolved constraints, evaluation findings, score or decision, required revisions, approval decision, corrections, escalation, stored object, identifier, storage receipt. Source identity, permission state, uncertainty, retention, and human decisions should travel with records rather than being discarded between stages.

Source provenance

  • Pattern ID: DP-014
  • Original title: Pattern 17: Challenging and Identifying Own Assumptions
  • Source location: SRC-001:P0331–P0355; page number unknown.
  • Source status: explicit.
  • Extraction notes: Canonical ID follows manuscript order. Legacy numbers are not used as publication identifiers; any numbered source heading is retained only for provenance and source fidelity.
  • Editorial interventions: The public title, summary, context, response and intended outcomes are concise editorial syntheses grounded in the source pattern. Original source prose is preserved below; workflows and modules remain separated and provenance-labelled.

Open questions

  • Which elements of this pattern require empirical or practice-based evaluation in the intended setting?
  • Which implementation examples remain current, authorised and proportionate to the setting at the time of use?