The dotSuper 0→1 Method: From a Real Constraint to the First Measurable System

0→1 means the first defensible operating change

dotSuper defines zero to one as moving from an important but insufficiently structured constraint to a first system that someone owns, real users can operate, evidence can evaluate, and a sponsor can decide about. 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

The five moves create discipline without becoming a rigid waterfall. 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.

1. Diagnose the real constraint

Diagnosis begins with the work as it is, not the process as a slide describes it. dotSuper identifies the sponsor, process owner, users, systems, handoffs, exceptions, evidence, and decision the engagement must enable. 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

Bounding freezes the baseline and scope, identifies approved sources and data, defines users and systems, records permitted and prohibited actions, and sets success, stop, and escalation criteria. 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

Smallest useful means the narrowest change that real users can apply to meaningful work and that creates evidence about the value mechanism. 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

Proof is multidimensional. 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

Early delivery contains manual judgment. 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

dotSuper's current portfolio has two entry points. 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.

What the method does not promise

The method does not guarantee rankings, AI citations, recommendations, lead volume, efficiency, pilot success, or transformation. 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.