StoryIQ — Signal to Story. Story to Pass.
StoryIQ is a seven-stage product, engineering, and QA approval workflow that connects acceptance criteria, evidence, verdicts, and a tamper-evident Pass Record.
By Khalil Abu Mushref · ·
Most delivery tools track that something happened. Very few prove what was actually done — with evidence, with sign-off, with a record nobody can quietly edit later.
That gap is where things break. A PO writes a story, an engineer ships it, QA gives a thumbs-up in chat, and weeks later nobody can answer the simplest question: what was passed, by whom, against what acceptance criteria?
StoryIQ was built to close that gap.
It is the IQ-suite product that sits between IdeaIQ (where opportunities are explored) and SquadIQ (where the active work board lives). StoryIQ is the layer in the middle—the approval workflow that turns a PO's observation into a traceable outcome with recorded evidence and decisions.
Signal to story. Story to pass.
The Idea Behind StoryIQ
The premise is simple: delivery without proof is a story you tell yourself.
In every team I have worked with, the last mile of a story — the moment between "I think it's done" and "we agree it shipped" — is the most fragile part of the system. It happens in DMs, in screenshots, in Jira comments that get rewritten, in QA verdicts that never get tied back to the original ask.
So we asked a different question:
What if the act of passing a story was itself a first-class object — versioned, signed, and locked?
That object became the Pass Pack, and the workflow around it became StoryIQ.
The 7-Stage Workflow
StoryIQ runs every story through a fixed left-to-right pipeline. Each stage has one owner, one exit gate, and one moment where the system says: not yet.
Signals → Ready → In Progress → Self Check → QA Review → PO Pass → Closed| Stage | Owner | Exit gate |
| --------------- | ------------- | ----------------------------------------------------------------------------- |
| Signals | PO | Title and acceptance criteria set |
| Ready | PO → Assignee | Self-claim or assigned |
| In Progress | Assignee | Self-checks complete |
| Self Check | Assignee | Pass Pack valid — whatChanged, primary link, every selfCheck done, ≥1 proof |
| QA Review | QA | Verdict recorded — pass or changes_needed |
| PO Pass | PO | Decision note on Pass Story or Request Changes |
| Closed | — | Terminal — application-locked poPasses snapshot with a SHA-256 digest |
The pipeline does not care how clever you are. It cares that every signal becomes a story, every story carries its own evidence, and every closed item carries a record nobody — including the PO who passed it — can rewrite later.
The Pass Pack
The Pass Pack is the centerpiece. Before a story can leave Self Check, the assignee has to fill it in:
- What changed — a plain-language description of the actual delivery
- Primary link — the canonical artifact (PR, deploy, document, dashboard)
- Self-checks — every line on the story's checklist marked done
- Proof — at least one artifact (screenshot, log, test run, recording)
Only then can QA pick it up. Only then can the PO pass it. And once the PO clicks Pass Story, the application locks the Pass Pack and stores a SHA-256 digest so later changes can be detected.
That creates a tamper-evident application record linking what was shipped to its evidence and decision. A hash alone does not make a record legally immutable or audit-certified; stronger guarantees require access controls, append-only storage, independent logs, and operational review.
Config-Driven, Not Code-Driven
StoryIQ inherits the PPLUS configuration pattern that runs through the rest of the IQ suite: every instance declares its own stages, status ranges, role mapping, SLA per stage, and product areas through a single instanceConfig.productConfig JSON blob.
That means an instance can:
- Rename stages without a deploy
- Adjust SLA windows per stage
- Swap PO / Dev / QA role mappings
- Add new product areas (journey × persona)
- Tighten or loosen Pass Pack requirements
…all from configuration. No migration, no release, no engineering ticket.
The workflow itself is driven by a Workflow Registry — workflowRegistry → workflowActivities → workflowActions → workflowConditions → slaPolicies — so the rules of the pipeline are themselves data, not code.
Cross-Product Events
StoryIQ does not live alone. Every state change emits a CloudEvent on the shared @iq/events bus, so the rest of the suite can listen:
iq.storyiq.signal.capturediq.storyiq.story.creatediq.storyiq.story.transitionediq.storyiq.passPack.completediq.storyiq.story.passed
SquadIQ subscribes so squad boards stay in sync. BoardIQ subscribes so the executive dashboard reflects what was actually passed — not just what was claimed. The signal-to-pass journey becomes one continuous, observable system across the suite.
Who StoryIQ Is For
StoryIQ is designed for teams whose delivery has consequences:
- Product Owners who need an honest answer to "what shipped this week?"
- Engineering leads tired of evidence living in Slack threads
- QA teams that want a fixed verdict object instead of comment-thread negotiation
- Compliance and audit functions that need a record they can trust without re-interviewing the team
If your team ships work and you cannot, in one click, retrieve the exact artifact, checklist, and decision behind a closed story — StoryIQ is built for you.
What's Next
This is StoryIQ v1.0—the foundation: seven stages, the Pass Pack, a tamper-evident application record, a config-driven workflow, and cross-suite events. The roadmap from here focuses on deeper signal capture, richer QA verdict objects, and tighter feedback loops back into IdeaIQ.
This portfolio case study documents the product direction and its evidence model. Public-facing product language and controls should be reviewed together before treating any record as audit-grade.
FAQ
What is StoryIQ?
StoryIQ is the IQ-suite approval workflow that turns a Product Owner's signal into a traceable outcome with acceptance criteria, evidence, QA and PO decisions, and a tamper-evident Pass Record. It sits between IdeaIQ, where opportunities are explored, and SquadIQ, where the active work board lives.
What is a Pass Pack?
It is the evidence object every story must carry before leaving Self Check: what changed in plain language, a primary link to the canonical artifact, every self-check marked done, and at least one proof. When the PO clicks Pass Story, the application locks the pack and stores its SHA-256 digest to make later changes detectable.
Can teams change the workflow without a deploy?
Yes. StoryIQ inherits the PPLUS configuration pattern: stages, status ranges, role mappings, SLA windows, and product areas all live in a single configuration blob, so an instance can rename stages or adjust SLAs with no migration, no release, and no engineering ticket.
Who is StoryIQ for?
Product Owners who need an honest answer to "what shipped this week?", engineering leads tired of evidence living in Slack threads, QA teams that want a fixed verdict object, and audit functions that need a record they can trust. It sits alongside the rest of my projects — and if that sounds like your team, get in touch.
Signal to story. Story to pass.
— Khalil