/ THE SHORT ANSWER
- 01The method begins with a business constraint and observed workflow, not an AI tool or content quota.
- 02A frozen baseline and approved evidence make later claims testable.
- 03The smallest useful intervention may be digitisation, rules automation, a copilot, a workflow, an agent, or an evidence-led inbound system.
- 04Human ownership and approval are placed at factual, data, publishing, and operational decision gates.
- 05The engagement ends with a decision and captured learning, not automatic expansion.
/ dotSuper point of view
The first system should be small enough to evaluate, real enough to matter, and governed enough to support a credible next decision; dotSuper turns the learning from that first bounded outcome into reusable operating capability.
0→1 means the first defensible operating change
Software or published pages alone are not the outcome.
The constraint may be weak B2B discovery despite strong proof, a manufacturing workflow dependent on paper or fragmented records, or a knowledge task slowed by search.
The method also allows a non-AI conclusion: standard work, data capture, analytics, or rules automation may be the right first system.
The five moves: Diagnose, Bound, Build, Prove, Productize
Discovery may narrow the scope; evaluation may reveal a missing data or adoption condition; productization may show that work still depends on expert judgment.
Each move creates a durable artifact and a gate so the team does not continue merely because work has started.
| Move | Core question | Primary artifacts | Decision gate |
|---|---|---|---|
| Diagnose | What real constraint, workflow, and decision matter? | Problem statement, current-state workflow, owner map, evidence gaps | Is the problem material, owned, and observable? |
| Bound | What is in scope, what is true, and what may the system do? | Frozen baseline, source-linked facts, data boundary, risk screen, success and stop criteria | Can a bounded intervention be run responsibly and measured? |
| Build | What is the smallest useful change? | Working asset or workflow, approvals, representative test set, operating instructions | Does it work well enough in the intended setting to continue testing? |
| Prove | What changed across quality, use, operations, risk, and value? | Evaluation results, user behavior, operating metrics, issue log, value analysis | Stop, revise, implement, subscribe, or scale? |
| Productize | Which repeated work deserves a reusable system? | Templates, standards, memory, controls, QA, dashboard, learning backlog | Can quality and economics hold beyond founder-led delivery? |
1. Diagnose the real constraint
Operating work may require interviews, records, and observation; inbound work requires the offer, buyer, proof, website, approval path, discovery baseline, conversion path, and lead response.
The aim is to separate causes from symptoms.
Low enquiries may reflect discovery, evidence, conversion, follow-up, or the offer.
Predictive-maintenance ambition may conceal missing failure labels or no ability to act on alerts.
The gate asks whether the constraint is material, owned, observable, and compatible with verified claims and appropriate data use.
Otherwise, rescope, foundation work, or decline.
- Name the business and process owner.
- Observe users and exceptions, not only the formal procedure.
- Identify the decision that better information or a new workflow should improve.
- Separate facts, evidence gaps, assumptions, and prohibited claims.
- Define what makes the problem worth solving now.
2. Bound the work before building
Limitations in the baseline remain visible.
For the Inbound Engine, this includes a source-linked Business Memory, a fixed buyer-question set, technical eligibility, observed discovery, conversion paths, and current pipeline measures.
Platform inclusion cannot be guaranteed, so controllable work stays separate from external outcomes.
For an AI Readiness Sprint, bounding includes the workflow, access, data, confidentiality, failure consequence, approval point, representative cases, and end decision.
Start read-only, draft-only, or non-destructive where that can create useful lower-risk evidence.
Missing baseline, permission, participation, or controls become foundation deliverables.
3. Build the smallest useful intervention
A mock-up that bypasses data, approvals, and exceptions cannot answer whether the system belongs in the workflow.
The intervention may be data capture, rules routing, a cited copilot, a defined AI workflow, a bounded agent, an evidence-rich buyer page, internal linking, or a conversion change.
More autonomy or more content is not inherently better.
Approval sits where factual, publishing, customer, data, financial, safety, or operating consequences change.
The reviewer receives sources, proposed action, uncertainty, and context.
Representative normal and exception cases—not only the happy path—support the build gate.
4. Prove what changed—and what did not
Technical evidence covers quality, robustness, latency, and cost.
Workflow evidence covers use, editing, overrides, handoffs, and exceptions.
Operating evidence covers the process KPI.
Risk evidence covers incidents and control performance.
Commercial evidence covers cost, qualified demand, avoided loss, or the relevant value mechanism.
Keep the measures separate: a strong model may be ignored; impressions may not create qualified conversations; an accurate alert may be unusable without lead time or parts.
NIST emphasizes contextual measurement, while GAO separates governance, data, performance, and monitoring.
Neither supplies a universal threshold for dotSuper.
The gate ends in a decision: stop, revise, implement, enter an optimisation cycle, or scale to a defined adjacent scope.
Stopping can be valuable when evidence prevents a larger bad investment.
- Technical: quality, groundedness, robustness, latency, and cost.
- Workflow: use, acceptance, editing, override, escalation, and completion.
- Operating: the process KPI and ability to act on the output.
- Risk: failures, incidents, control performance, and affected-user feedback.
- Commercial: cost, capacity, qualified demand, avoided loss, or other value mechanism.
5. Productize what repeats, not what merely looks repeatable
Productization identifies which repeated decisions, artifacts, controls, and measurements can become reliable modules. dotSuper records objections, intervention time, data gaps, approval latency, exceptions, feedback, outcomes, and failed assumptions in a learning ledger.
Repeated work may become an assessment, template, Business Memory schema, question map, approval matrix, evaluation pattern, workflow, dashboard, or monitoring routine.
Context-sensitive judgment remains explicit.
The gate asks whether scope, quality, client ownership, cycle time, and economics can hold beyond founder-led delivery; otherwise the answer is a narrower offer or more learning.
Two entry products, one operating logic
The Inbound Engine is for evidence-rich B2B firms with a credible offer, usable proof, a functioning website, approvals, and lead response—but weak discovery or conversion.
It connects approved business memory, buyer questions, evidence-rich assets, technical and authority work, conversion, and measurement.
The AI Readiness Sprint is for a material operating pain with weak process visibility, fragmented data, limited digitisation, or no prioritized opportunity.
It produces the current workflow, diagnosis, ranked opportunities, one starting point, a first blueprint, owners, controls, measures, and next decision.
Products are not automatically cross-sold; routing follows the constraint and evidence.
| Starting condition | Likely route | First bounded outcome |
|---|---|---|
| Credible B2B offer and proof, but weak discovery or inbound conversion | Inbound Engine | Measured 90-day discovery, evidence, content, conversion, and learning system |
| Material operating pain, but fragmented workflow, data, or priorities | AI Readiness Sprint | Implementation-ready first-step decision and blueprint |
| No accountable owner, unverifiable claims, inappropriate data, or no measurable problem | Foundation work, rescope, or decline | Evidence and conditions required before a build |
What the method does not promise
Platforms, buyers, operating conditions, data, adoption, and client execution affect outcomes; forecasts must expose assumptions and uncertainty.
AI is not assumed to be the destination.
The method may recommend process work, digitisation, rules automation, a human-owned copilot, a defined workflow, or no project.
Its narrower commitment is to make the constraint, evidence, scope, ownership, intervention, measurement, and next decision explicit.
What this page cannot conclude
- 01The 0→1 method is dotSuper's working methodology and had not been independently validated as of the publication date.
- 02The current product portfolio, scope, timing, routes, and terminology come from a working draft and require product-owner approval before public launch.
- 03External NIST, GAO, and Anthropic sources support component practices; they do not endorse dotSuper or guarantee its delivery outcomes.
- 04No method can guarantee rankings, AI citations, leads, ROI, pilot success, or transformation.
- 05Legal, privacy, security, safety, sector, and country requirements require appropriate professional review.
Sources
- 01NIST AI RMF PlaybookNational Institute of Standards and Technology · accessed Aug 30, 2026
- 02AI measurement and evaluationNational Institute of Standards and Technology · accessed Aug 30, 2026
- 03Artificial Intelligence: An Accountability Framework for Federal Agencies and Other EntitiesU.S. Government Accountability Office · accessed Aug 30, 2026
- 04Building effective agentsAnthropic · accessed Aug 30, 2026
Our editorial standard · Found an error? Send a correction with its source.
/ CITE OR SHARE THIS GUIDE
Make the evidence easy to verify.
When you reference this guide, link to its canonical URL. That gives readers one stable place for the evidence, limitations and future updates.
dotSuper Research Desk. (August 30, 2026). The dotSuper 0→1 Method: From a Real Constraint to the First Measurable System. dotSuper. https://dotsuper.net/feeds/applied-systems/from-constraint-to-measurable-system