The Two-Week Readiness Test: Go, No-Go, or a Dated Fix List

Two weeks is enough to know whether a manual process is consistent enough to automate. Not a quarter. Not a 40-page maturity report with a radar chart on page 12 that nobody opens after the kickoff meeting. Two weeks.

The reason is simple. "Are we AI-ready?" is an abstract question, and abstract questions produce abstract answers. The useful question is narrower: when a human runs this process today, does the same input reliably produce the same steps and the same output? If your team can't agree on how the process runs, no model will fix that. The honest answer is a no-go, and you should hear it before you fund a build.

What a two-week AI readiness assessment should decide

A readiness assessment has exactly three acceptable outputs:

• Go. A scoped workflow, with defined inputs, steps, outputs, and an evaluation gate, ready to hand to a Pilot-to-Production Build.
• No-go, with the reason. Inputs vary too much. The data the workflow needs doesn't exist or lives somewhere nobody can legally touch. The process gets rewritten every quarter. A named reason, not a vibe.
• A dated fix list. Named owners, named gaps, and a date to re-check. "Finance standardizes the intake form by end of next month, we re-run the variance sample then."

Anything else is a slide deck. Our hero line already says what we think of those: AI that works inside your business, not in a slide deck.

If you've been burned by an assessment that graded your "data maturity" and then left, your readiness assessment was probably testing the wrong thing. Data volume rarely decides it. Process consistency does, which is also why "do we have enough data?" is the wrong first question.

What the sprint actually inspects, week by week

Our AI Opportunity & Readiness Sprint is a 2-week, fixed-fee engagement. Here's the methodology, laid out in the open, because most teams won't run it themselves anyway and the ones who do should run it properly.

Shadow the real process, step by step

We sit next to the person who does the work and write down every step, including the ones they forgot to mention. The copy-paste from the PDF into the CRM. The Slack message to check one field. The spreadsheet that only one person understands. The documented process and the real process are usually different documents, and only the real one matters.

Sample real inputs for variance

We pull a sample of real inputs, not the clean examples someone picked for the demo. Are the intake forms structured or freeform? Do half of them arrive as scanned images? Do two people handle the same input differently? High variance isn't automatically a no-go, but it changes what you'd build and how long it takes.

Map where the data lives and who can touch it

Every step needs data from somewhere. We map each source, who owns it, and who is allowed to read or write it. This is where a lot of "easy" use cases quietly die, and it's far cheaper to find out here than in week six of a build.

Sketch the evaluation gate

Before anyone writes a prompt, we define what "good enough to ship" means: which outputs get checked, against what, and what failure rate is acceptable before a human must review. If nobody can describe a correct output, nobody can test one. That's a fix-list item.

Translate the tech into removed steps

We don't pitch architectures. We describe what changes in the workflow. Retrieval (RAG) means the analyst stops opening four systems to find the right policy clause. An agent means the three-system lookup, the field mapping, and the confirmation email become one reviewed action. If a technique doesn't remove a manual step, it doesn't make the plan.

Security and governance start on day one, not week ten

For CTOs and CISOs, this is the part that decides whether a go is real. The sprint flags three risks early:

• Data boundaries. What the workflow can retrieve, and whether that scope matches who's asking. Most teams never consciously make this permissions decision; it gets made by default inside a vector index.
• Prompt-injection exposure. If the workflow reads emails, uploaded documents, or web content, untrusted text is reaching your model. We note where, and what that text could trigger.
• Excessive agency. Which actions the workflow would take on its own, and which need a human sign-off.

We map these to frameworks your team already reports against, the NIST AI RMF and the OWASP LLM Top 10, so the findings land in your existing risk process instead of a parallel one. A go that ignores the CISO is a no-go with a delay.

Why a clear go makes budgets defensible

This is planning season. Leaders are building the case for next year, and "we think AI could help with intake" doesn't survive a budget review. "We tested intake for consistency, here's the scoped workflow, the eval gate, and the security review" does.

A clear go is also what lets a build move fast. Two examples from our own work:

• PolicyFlow, an AI-powered insurance data intake product: one senior engineer plus an AI co-pilot shipped in 3 months what would have taken a 4-person team 12 months.
• SoloStream: built by one engineer with an AI co-pilot in about 3 months, at roughly 80% lower cost than a traditional build of around $500k.

Neither timeline came from heroics. Both started with knowing exactly what to build, which inputs to expect, and what "done" looked like. Fuzzy scope is where builds lose months. You can see more of the shipped work on our ventures page.

A no-go is valuable too. It's the cheapest line item you'll approve all year, because it kills the project that would have eaten a quarter and stalled in pilot.

Run a rough version yourself first

Before planning cycles lock, grab our readiness checklist. It covers the consistency, data, and governance questions the sprint asks: how many people run the process, whether they'd describe the steps the same way, where each input comes from, who can access it, and what a correct output looks like. Score your top roadmap candidate honestly and you'll have a rough go, no-go, or fix list in an afternoon. Download it at horizontwolabs.com.

So here's the real test: which process on your roadmap could survive a two-week consistency check right now, and which one are you budgeting for on hope?