Workflow Specification
The exact sequence of steps, decision points, exceptions and handoffs a solution must support — grounded in the Current-State Workflow Model produced during discovery, not a reimagined ideal process.
Solution Design · Step 03 · How We Work
A Specification Is Not a Guess.
Strategy & Architecture defines how a system should be structured. Solution Design determines exactly what gets built — the specific workflows, interfaces, data contracts and failure behaviors that turn an engineered direction into something a team can actually construct.
This stage does not begin with an implementation. It begins with a specification that has been tested against evidence before a single line of production code is written.
Not this question
"What should we build?"
This question, instead
"Does this specific design actually behave the way we expect, under the conditions it will really face — and can we prove that before committing engineering effort to build it?"
Design · Prototype · Test · Measure · Specify
Why Design Follows Architecture
A Structure Is Not Yet a System.
The reference architecture from the previous stage defines layers, technology choices and cross-cutting concerns. It does not yet define how a specific workflow should behave when a request is ambiguous, or what happens when an integration returns malformed data. Solution Design closes that gap — without it, "architecture" remains a diagram, not a system.
Reference Architecture → Solution Specification
Why Design Rigor Matters
The Cost of a Mistake Grows With Every Stage It Survives.
Barry Boehm's research into software engineering economics — first published in 1976 and expanded in his 1981 book Software Engineering Economics — found that the cost of correcting a defect grows substantially the later it is discovered.
~1×
Cost to fix a defect caught during design.
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
10×–100×
Cost to fix the same defect after production release, depending on project scale.
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
This finding has been revisited since. Boehm and Basili's own 2001 revision found the curve is meaningfully flatter for smaller, fast-iterating teams with strong testing and continuous delivery. The multiplier is not universal, and we do not treat it as one.
But the direction of the finding has not been overturned: catching a design flaw before it is built is cheaper than catching it after. This is why OpenQCore treats prototyping and testing as part of design itself — not as a phase that happens once building has already started.
From Architecture to Specification
Turning Layers Into Decisions a Team Can Build From.
Every architectural decision from the previous stage gets decomposed into concrete specifications.
Interface Specification
What each user, system or agent actually sees, sends and receives — screens, conversational flows, API contracts, and the fields that matter at each step.
Data Contract Specification
The exact shape, validation rules, versioning approach and ownership of data moving between components.
Behavioral Specification
What the system does — and explicitly does not do — under normal conditions, edge cases, and failure conditions.
Output
Solution Specification (Draft)
Workflow & Interaction Design
Design the Work, Not Just the Interface.
A conversational interface layered on top of a broken workflow does not fix the workflow — it hides it, until the underlying constraint resurfaces somewhere else.
Solution Design starts from the workflow evidence gathered during discovery, and asks a structural question before an interface question: which steps in this process should be automated, which should remain human, and where exactly does responsibility hand off between them? We map this explicitly, so that human-in-the-loop points are a deliberate design decision — not an accident of what the technology happened to be capable of.
Human-in-the-Loop Points
Explicit checkpoints where human review, judgment or authorization is required by design — not by omission.
Automation Boundaries
Precisely defined limits on what a system is permitted to decide or execute without human sign-off.
Exception Pathways
Designed routes for cases that fall outside normal handling — not silent failures or default fallbacks.
Prototyping & Experimentation
Design as a Testable Hypothesis, Not a Finished Answer.
OpenQCore treats early-stage design the way design science treats an information systems artifact: as something built specifically so it can be evaluated against a real problem, not simply admired for its elegance. This approach — formalized in Hevner et al.'s influential Design Science in Information Systems Research (MIS Quarterly, 2004) — treats the artifact and its evaluation as inseparable. We apply the same hypothesis-driven reasoning used during discovery, at the design level.
01
Design
A specific, falsifiable design decision — not a vague direction.
02
Prototype
A working representation sufficient to test the decision — not necessarily production-grade.
03
Test With Representative Data
Real or realistically representative inputs, not idealized examples chosen to succeed.
04
Measure Against Baseline
Comparison against the baseline and success criteria established during discovery — not a subjective impression of quality.
05
Refine or Reject
The design is kept, modified or abandoned based on what the test showed — not based on how much work has already gone into it.
The objective of a prototype is not to demonstrate that a design can work. It is to determine whether it reliably does, under the conditions the finished system will actually face.
Data & Interface Specification
Precision Here Prevents Ambiguity Later.
Integration failures rarely originate from a single obviously wrong decision. They tend to originate from ambiguity — a field that was assumed to always be present, an error case nobody wrote down, a version mismatch nobody planned for.
Schema DefinitionsValidation RulesError & Exception HandlingVersioning StrategyRate & Load BoundariesAuthentication & Authorization ContractsIdempotency Requirements
This is deliberately unglamorous work. It is also the work that determines whether a system that performs well in a demo continues to perform well in production, six integrations and eighteen months later.
Designing for Failure, Not Just Success
Every Demo Succeeds. Not Every System Does.
Most design failures are not failures of the happy path. They are failures of what happens when something goes wrong — an upstream system times out, a document doesn't extract cleanly, a model is uncertain, a user does something unexpected. OpenQCore designs these conditions deliberately rather than discovering them in production.
Uncertainty Handling
What the system does when confidence in an output is low — including whether and how it says so.
Graceful Degradation
What functions remain available when a dependency fails, rather than a full-system outage.
Escalation Design
The specific conditions under which a case is handed to a human, and what context that handoff carries with it.
Adversarial & Edge-Case Behavior
How the system behaves under malformed input, unexpected sequences, or attempted misuse — not just well-formed requests.
A system that has never been asked "what happens when this fails?" has not really been designed. It has only been demonstrated.
Validation Criteria Defined Before Build
Acceptance Criteria Come Before the Code, Not After.
Consistent with the principle established during discovery — that success must be defined before implementation — Solution Design produces explicit, written acceptance criteria and a test plan before production development begins.
Functional Acceptance Criteria
What the solution must correctly do, stated in testable terms.
Non-Functional Acceptance Criteria
Consistent with recognized software quality characteristics — including performance efficiency, reliability, usability, security and maintainability, as organized by ISO/IEC 25010's software product quality model — specified as measurable targets rather than general aspirations.
Test Plan
The specific scenarios, data sets and conditions the solution will be evaluated against before it is considered ready to build in production form.
The Design Review Gate
Design Ends With a Decision — Not an Automatic Green Light.
This practice has precedent: Michael Fagan's formal design and code inspection method, introduced at IBM in 1976, established that structured, criteria-based review catches defects earlier and more reliably than informal approval. OpenQCore applies the same principle to solution design.
Proceed to Build
The specification is sufficiently precise, the prototype met its evaluation criteria, and development can begin.
Iterate Design
The core direction is sound, but specific elements need revision based on what testing revealed.
Return to Architecture
Design work revealed a constraint the architecture did not account for — the appropriate response is revising the structure, not designing around it.
Escalate Risk
Design work surfaced a risk — technical, operational, security or ethical — that requires a decision above the design team's authority before proceeding.
A design gate that always says yes is not a gate.
What Solution Design Produces
Specifications a Team Can Actually Build From.
Depending on engagement scope, this stage produces:
Solution Specification Document
Workflows, interfaces, data contracts and behavior, in enough detail to build from without re-deriving intent.
Interaction & Workflow Diagrams
Visual representations of process flow, including explicit human-in-the-loop points.
API & Data Contracts
Schemas, validation rules and versioning strategy for every interface between components.
Prototype Evaluation Report
What was tested, against what baseline, and what the results support or rule out.
Failure Mode Analysis
Documented failure conditions and the designed system response to each.
Acceptance Criteria & Test Plan
The specific, measurable conditions the built solution must satisfy before deployment.
From Design to Development & Integration
A Specification Is Not Yet Software.
Solution Design produces a tested, validated specification — not a finished system. The next stage turns that specification into working software, integrated with the systems it must operate alongside.
Solution Specification → Prototype Evaluation → Acceptance Criteria → Development & Integration
Step 04
Development & Integration
Build the specified solution against defined acceptance criteria — not against assumption.
Research & Methodological References
Boehm, B. — Software Engineering Economics (1981); Boehm, B. & Basili, V. — "Software Defect Reduction Top 10 List," IEEE Computer (2001)
Source of the cost-of-change findings referenced above, including the later revision showing a flatter curve for smaller, fast-iterating teams.
Hevner, A., March, S., Park, J., & Ram, S. — "Design Science in Information Systems Research," MIS Quarterly (2004)
Foundational framework for treating an information systems artifact and its evaluation as inseparable — the basis for the prototype-test-refine cycle described above.
Fagan, M. — "Design and Code Inspections to Reduce Errors in Program Development," IBM Systems Journal (1976)
Origin of structured, criteria-based design review as a formal engineering practice, referenced in the Design Review Gate above.
ISO/IEC 25010:2011 — Systems and Software Quality Requirements and Evaluation (SQuaRE) — System and Software Quality Models
Source of the non-functional quality characteristics referenced in the acceptance criteria above.