Cheap to build, expensive to decide

For thirty years the scarce thing in software was the building. Hands were few, so the backlog ran long. Then the hands stopped being scarce: an agent writes the feature, a second reviews it, and a service-desk manager stands up an internal tool over a lunch break. The queue drained, and the obvious conclusion was that the constraint had gone.

It didn't. It moved, off engineering and onto the business, onto the slow work of deciding what is worth building and being able to say it precisely. Building is no longer the brake. Deciding is.

The bridge we already tried

We have bridged business and engineering before, and we have a name for the version that fails: the proxy Product Owner. Someone who relays requirements one way and status the other, with authority over neither. Scrum.org files it under anti-patterns, because a go-between who cannot decide is a bottleneck with a nicer title.

Point AI at that seam and the temptation is to automate the relay. But a relay without judgment does not become judgment when you make it faster. It becomes a bottleneck at machine speed, and if you bolt a warm, confident voice on top it becomes worse: a tool performing an authority it does not have. People feel the fake.

Two jobs under one title

The work on that seam is really two jobs. One is technique: turning a vague intent into precise terms, a data model, acceptance criteria. The other is judgment: what this is worth, which trade-off to accept, who gets to say yes. The first is automatable, because it is skill. The second is not, because it is mandate.

Keep them apart and the tool designs itself. Automate the technique, leave the judgment with the person who holds the mandate, and build the tool so it knows the difference. That tool is what we are building. We call it Clarion.

What Clarion has to do

Most of the requirements are restraint, not cleverness.

• Speak to the business, not the developer. The way in is a conversation, not a command line.
• Leave an inspectable spec, with its provenance. Every term carries where it came from, so when claims conflict the order of trust is visible rather than buried in a model. Readable by an auditor, and per decision by a customer.
• Force the right question. Ask for a balance sheet and a model gives you one, but a tax balance sheet and a trial balance are different documents. Clarion refuses an undefined term and asks which you meant, before a line is built.
• Surface, never decide. When the spec drifts from strategy or two stakeholders collide, it sets the claims beside their evidence and hands the call to whoever holds the mandate. It never wears that decision as its own.
• Record what matters, not everything. A spec that hoards every utterance rots by the third month. It keeps the terms and decisions that recur, and the dissenting voice instead of a bland average.
• Deterministic where it can be, and regulated-ready. Reach for a model only where judgment is needed, and keep the audit trail the regulator will ask for.
• Breathe Scrum principles, ignore the dogma. The increment leads and evidence settles arguments; priorities stay economic and get re-ranked, not frozen into a must-have list where everything is a must.

What the field already has

Hold the market against three questions. Does it face the business rather than the developer, leave an open specification you can inspect, and fit the enabling world, the one where software serves a process it is not itself the product of, which in banking, insurance and logistics also makes it regulated?

• Spec-driven frameworks (BMAD, Spec Kit, Kiro, Tessl) put the spec first, but every one is built for a developer at a terminal.
• Product suites (ChatPRD, the AI in Jira, Confluence, Productboard) face the business, yet ship prose.
• Requirements platforms (Jama, DOORS) are inspectable and regulated-ready, but heavy and engineer-facing.
• Decision engines are business-owned and auditable, but encode the rules a live system runs on, not build-time specs.

No single tool combines all three: a front door for the business, an open specification anyone can inspect, and a fit for the enabling, regulated world where the brake now lives.

This is not theory. Across our interviews, inside Baseflow and outside it, the same pattern keeps surfacing: experienced product people have already built a crude version by hand, letting an AI interview them feature by feature while a swarm of agents builds and a second agent reviews. It works. And every time, the nearest tool was a developer's framework bent into the shape of a Product Owner.

Built in the open

Clarion goes into that empty space, and it is being built in the open. What it has to earn is trust, and trust does not survive a black box with a warm voice. A specification you cannot read is the old proxy problem again: an authority nobody can inspect.

So before you reach for a machine to sit on that seam, write two lists: what it must do, and what it must never pretend. The second list is the harder one, and it matters more. A translator is honest about what it is not: it holds no mandate, and it says so. Drop that list, and you have not built a translator.

You have just automated the proxy Product Owner.