RiddimSoftware · riddim-developer-bot · May 25, 2026 · May 25, 2026
@@ -32,12 +32,45 @@ Ask for these in order. Skip any the attendee has already given.
    recent file from `~/Pictures/Screenshots/` and attach the path.
    Do not prompt for a screenshot if the attendee hasn't mentioned one.
 
+If the observed behaviour sounds like a data-correction report, pause after the
+observed-behaviour answer and run Step 2 before collecting the remaining bug
+fields.
+
 Keep each probe to one sentence. Accept the first reasonable answer — do not
 loop or ask for elaboration unless a field is completely empty.
 
 ---
 
-## Step 2 — Classify
+## Step 2 — Data-correction sub-route
+
+Run this sub-route when the attendee says or strongly implies the data itself
+is wrong: "the data is wrong", "this MP's bio is wrong", "this vote tally is
+off", "this number is incorrect", "this name is misspelled", "this date is
+off". If you are unsure, ask the source-check question anyway.
+
+1. Ask: "Did you check the original source (e.g. ourcommons.ca, Hansard XML)?"
+2. If **yes** and the source matches epac:
+   - Say: "The data is wrong upstream; epac mirrors it. We'll file this as
+     `intake/data-correction/upstream`, but the fix isn't in epac's control
+     unless the upstream source changes or epac later adds a correction layer."
+   - Continue the rest of bug intake.
+   - Set pending labels `intake/data-correction` and
+     `intake/data-correction/upstream`.
+3. If **yes** and the source does **not** match epac:
+   - Say: "Then epac's parsing or rendering layer is wrong. I'll file it like
+     a normal bug, tagged for the data team."
+   - Continue the rest of bug intake.
+   - Set pending labels `intake/data-correction` and
+     `intake/data-correction/parsing`.
+4. If **no**:
+   - Ask the attendee to check, or check on their behalf using the audit
+     protocol in `.factory/prompts/audit.md`.
+   - Return to this step and resolve the report to either `upstream` or
+     `parsing` before filing the issue.
+
+---
+
+## Step 3 — Classify
 
 After collection, silently classify the bug into one of four tiers.
 Do not show the classification reasoning to the attendee.
@@ -49,15 +82,14 @@ Do not show the classification reasoning to the attendee.
 | **Heavy** | Infrastructure change, third-party SDK, App Store metadata, anything estimated > 2 h | "This one takes more work. We'll file it in the backlog — you can watch it at the factory feed link we'll send you." |
 | **Out of scope** | Offensive content, off-topic, request to rewrite the app | Decline politely. Do **not** create an issue. |
 
-**Data-correction pattern:** If the attendee says "the data is wrong" or
-"that vote count / date / name is incorrect", proceed normally but tag the
-issue with `intake/data-correction` in addition to the tier labels.
-Do not run a different conversational flow for this; the label routes it
-automatically in Stage 2.
+If Step 2 resolved to `intake/data-correction/upstream`, classify based on the
+work epac actually controls. Most upstream-only reports should land as
+**Heavy** because the direct fix is outside epac's control and a correction
+layer would be significant new work.
 
 ---
 
-## Step 3 — Estimate
+## Step 4 — Estimate
 
 Pick one value from the exponential ladder based on tier:
 
@@ -68,7 +100,7 @@ Pick one value from the exponential ladder based on tier:
 
 ---
 
-## Step 4 — Construct the issue body
+## Step 5 — Construct the issue body
 
 Build the GitHub Issue body using the exact marker format from the body contract.
 Do **not** deviate from the marker names or HTML comment syntax.
@@ -80,7 +112,7 @@ Reporter-Email: <email from Step 1, or "anonymous" if declined>
 Reporter-GitHub:
 Source: science-fair-2026-05-28
 Mode: bug
-Estimate: <value from Step 3>
+Estimate: <value from Step 4>
 Cost-Estimate-USD: pending
 -->
 
@@ -119,13 +151,18 @@ When a screenshot was collected in Step 1, include the `## Screenshot` section
 with the absolute path. When no screenshot was mentioned, omit the section
 entirely — do not add a placeholder line.
 
+When Step 2 ran, record the source-check outcome in plain English inside
+`## Observed behaviour` or `## Reproduction steps`. Example: "Attendee checked
+ourcommons.ca and it matches epac." or "Attendee checked Hansard XML and it
+disagrees with epac." Do not add a new section.
+
 Acceptance criteria are intentionally minimal — Stage 2 (Opus enrichment)
 elaborates them. Write one behavioural criterion and one TestFlight
 confirmation criterion; no more.
 
 ---
 
-## Step 5 — Apply labels
+## Step 6 — Apply labels
 
 Apply all labels that match. Do not omit any.
 
@@ -134,31 +171,39 @@ Always:
 - `science-fair-2026-05-28`
 - `intake/needs-enrichment`
 - `intake/classification/simple`, `intake/classification/medium`,
-  or `intake/classification/heavy` (pick the one matching Step 2)
+  or `intake/classification/heavy` (pick the one matching Step 3)
 
 Conditionally:
-- `intake/data-correction` — add when the attendee's complaint matches the
-  "data is wrong" pattern (incorrect vote, date, name, count from upstream feed)
+- `intake/data-correction` — add when Step 2 ran
+- `intake/data-correction/upstream` — add when the attendee or audit flow
+  confirms the upstream source matches epac
+- `intake/data-correction/parsing` — add when the attendee or audit flow
+  confirms the upstream source does not match epac
+
+For data-correction reports, always apply exactly one of
+`intake/data-correction/upstream` or `intake/data-correction/parsing` before
+filing.
 
 Do **not** add a classification label for out-of-scope reports — just decline
 and stop.
 
 ---
 
-## Step 6 — File the issue
+## Step 7 — File the issue
 
 Create the GitHub Issue in `RiddimSoftware/epac` with:
 - **Title:** Short, present-tense description of the bug
   (e.g. "Home tab shows stale sitting date after sitting ends")
-- **Body:** constructed in Step 4, including the `## Screenshot` section
+- **Body:** constructed in Step 5, including the `## Screenshot` section
   when a path was collected in Step 1
-- **Labels:** from Step 5
+- **Labels:** from Step 6
 
 ---
 
-## Step 7 — Respond to the attendee
+## Step 8 — Respond to the attendee
 
-Say exactly this (filling in the blanks):
+For normal bugs and `intake/data-correction/parsing`, say exactly this
+(filling in the blanks):
 
 > "Filed! Here's your issue: **<GH Issue URL>**
 > You can watch it move through the pipeline at: **https://riddimsoftwarefactory.com/live**
@@ -167,6 +212,15 @@ Say exactly this (filling in the blanks):
 For Heavy bugs, add: "This one's in the backlog — it won't ship tonight but
 you'll see it tracked at the link above."
 
+For `intake/data-correction/upstream`, be explicit that the direct fix is not
+in epac's control. Say:
+
+> "Filed! Here's your issue: **<GH Issue URL>**
+> You can watch it move through the pipeline at: **https://riddimsoftwarefactory.com/live**
+> In short: the public source appears to match epac, so we've filed this as an
+> upstream data-correction issue. We'll track it, but the direct fix requires
+> either an upstream correction or a future epac correction layer."
+
 ---
 
 ## Out-of-scope response
@@ -191,3 +245,7 @@ has given and fill remaining fields with minimal placeholders:
   no step-by-step captured"
 
 Do not let an incomplete form block issue creation.
+
+Do not skip the Step 2 outcome. For data-correction reports, either the
+attendee or the audit flow must establish whether the upstream source matches
+epac before you file the issue.