What is question-to-outcome traceability?
Traceability is a two-way link between an input and every output that depends on it. Forward tracing starts with a question and follows each possible answer to scoring, result, route, storage, and follow-up. Reverse tracing starts with an output—such as a specialist-review route—and identifies the supplied answers and deterministic rules that can produce it.
A data dictionary explains fields. A traceability matrix goes further by recording the purpose, decision rule, participant-visible effect, stored value, downstream action, test, owner, and review date. That makes the implemented funnel reproducible instead of relying on the builder's memory.
Related: Design qualification questions that earn their place · Document transparent scoring rules
Build one row for every answer-dependent rule
Use one row per answer-dependent rule, not merely one row per screen. A single question may need several rows when different answer bands change different outcomes. Stable input and output identifiers should match the identifiers used in analytics, stored records, exports, and test evidence.
| Field | Record | Release question |
|---|---|---|
| Input ID | Stable question and answer identifiers | Can analytics, storage, and exports use the same IDs? |
| Participant meaning | What the person is being asked | Is the wording understandable without internal jargon? |
| Purpose | Result, qualification, route, follow-up, consent, or operations | Is the purpose specific and current? |
| Rule | Exact value, band, weight, or condition | Can another reviewer reproduce it? |
| Visible output | Result text or next question | Does the participant see the intended consequence? |
| Stored output | Raw answer and derived field | Are observation and inference stored separately? |
| Downstream action | Segment, message, assignment, or suppression | Does the receiving system get the same context? |
| Test and owner | Input, expected output, evidence, role, and review date | Who proves the rule and corrects drift? |
Separate observations, derivatives, inferences, and human status
A supplied observation is what the participant selected or entered. A deterministic derivative is a score, band, or route calculated by a documented rule. An operational inference is an interpretation used for prioritization or follow-up. Human status is a later review, qualification decision, or sales disposition.
Do not overwrite an observation with an inference. Keeping these layers distinct lets a reviewer determine whether an unexpected result came from the answer, the calculation, the workflow, or a later human decision.
Run forward and reverse traceability checks
For the forward check, choose every answer option and record the displayed result, stored fields, emitted event, and downstream payload. For the reverse check, take each result and operational action and identify the exact inputs and rule that can produce it.
An output with no supporting input is an orphan outcome. An input with no participant-visible or operational effect is an unused collection point. Resolve both before release: repair the rule, document the requirement, remove the output, or stop collecting the input.
Related: Test every reachable branching path · Audit result-page claims against their inputs
Use six blocking test cases
Record expected and actual evidence at every layer. A rule passes only when the visible result, stored record, analytics event, and downstream action agree. Test synthetic records so they cannot be mistaken for real prospects.
| Test | Input | Expected evidence | Blocking failure |
|---|---|---|---|
| Ordinary path | Representative valid answers | Correct result, fields, event, and follow-up | Any layer disagrees |
| Boundary | Values immediately around a threshold | One predictable transition | Gap, overlap, or wrong tie handling |
| Missing optional | Optional item skipped | Valid result with no invented value | A default silently changes the result |
| Reload or resume | Persisted partial state | Same answer IDs and rule version | Stale or duplicated state |
| Rule update | Previous record reopened | Original calculation remains explainable | Historical result changes silently |
| Downstream retry | First delivery fails | One idempotent retry and visible recovery state | Duplicate lead or lost context |
Worked example: find an unused company-size question
Suppose a service-fit quiz asks about goal, timing, operating constraint, willingness to involve a specialist, and company size. Goal changes the recommended path. Timing changes an urgency band and follow-up delay. The constraint changes the result explanation. The specialist answer controls handoff permission.
The matrix reveals that company size is stored but changes no result, route, qualification rule, or follow-up. Unless a documented operational requirement exists, remove it or collect it later. This illustrates the audit; it is not a real campaign result or a claim that company size is never useful.
Check understandable input and necessary collection
W3C form guidance calls for clear labels, instructions, required or optional status, expected formats, and accessible validation. Test the human-readable prompt and the stable field ID together. A technically traceable field is still defective if a participant cannot understand or correct it.
The ICO data-minimisation principle says personal data should be adequate, relevant, and limited to what is necessary for the specified purpose. Treat every empty-purpose row as a deletion candidate. The ICO states that this guidance is under review following the Data (Use and Access) Act, so recheck it before relying on the details. This guide is implementation guidance, not legal advice.
Related: Review the complete quiz data-privacy checklist
Sources: W3C, Form instructions · W3C, Validating input · ICO, Data minimisation principle
Use this blocking release checklist
Release only when another reviewer can reproduce every defined connection from the recorded inputs, rules, versions, and evidence.
- Every required question maps to a defined participant or operational outcome
- Every result, route, segment, and follow-up maps back to supplied inputs and a versioned rule
- Observations, derivatives, inferences, and human statuses remain distinct
- Boundary, missing, reload, retry, and historical-rule cases pass
- Visible results, stored records, events, and downstream payloads agree
- Unused or excessive personal fields are removed or deferred
- Labels, instructions, validation, focus, and keyboard behavior pass manual review
- The owner, verification date, limitations, sources, and correction path are recorded
Evidence
How to reproduce the method
Reproduce the method with the forward-and-reverse traceability matrix, the orphan-input and orphan-output audit, and six blocking test cases. The artifact records stable IDs, exact rules, visible and stored effects, downstream actions, evidence, owners, and review dates without requiring access to a particular product account.
Limitation
Where this conclusion stops
The matrix proves implementation consistency, not scientific validity, fairness, legal compliance, or improved conversion. High-stakes decisions need appropriate subject-matter, legal, privacy, and fairness review. The example is illustrative; no product, campaign, or performance benchmark was tested for this guide.
Sources and verification
What this guide relies on
- The Lead Quiz Review editorial methodology
- W3C, Form instructions
- W3C, Validating input
- ICO, Data minimisation principle
Sources and method checked September 16, 2026. External standards are linked to their primary publishers. Request a factual correction.