The product is a structured model of the business; the application is a projection of it

Every AI application builder can emit code. Code is semi-structured: it can be generated, and it can be compiled, but it cannot be reasoned over as a description of a business. The answers to “which requirement does this screen serve”, “which role may reach this record” or “what does this feature owe a regulator” are in the code somewhere, in the way a novel’s plot is in its letters. A generator asked those questions can only generate more code.

Paul’s own statement of the bet, recorded in messaging.md:

The bet of Wildo is that structured data, avoiding the more complex parts of applications, and focusing on a sub-domain, B2B SaaS and corporate internal tools, makes it possible to define needs well beyond application creation alone. We determine the business way with the product, together. That the data is structured, and not only semi-structured, is key.

The distinction that matters is between a specification that is prose and a specification that is data. A prose specification is what language models are best at producing and what most spec-driven tooling has converged on. It reads well and it refuses nothing. You cannot run a set operation over it: you cannot ask it, exactly and for free, which of its requirements no task decomposes. A typed model can be asked, and the answer is a computation rather than an opinion.

• Every part of the product definition is a schema-backed file family. The market snapshot, the domain plan and the compliance documents are Zod-typed values landed as TypeScript files in the application’s own specifications package, not documents beside the repository. Rejected: a prose brief per phase. Prose cannot be cross-referenced by identifier, so nothing downstream could be checked against it.
• Families reference each other by ref, never by name in a sentence. A roadmap phase names the success criteria it delivers; a document clause names the facts it cites. Rejected: free-text links. They cannot dangle visibly, which means they dangle silently.
• Cross-family questions are answered by a derived report, not by a reviewer’s memory. The coherence report is a pure function over the landed families and is recomputed from the working tree on demand. Rejected: a stored coverage matrix. A stored answer goes stale the moment a family moves, and a stale answer reads exactly like a current one.
• The report informs; it does not refuse. A coverage gap is frequently legitimate: a success criterion deferred past the current horizon is a gap and is correct. Rejected: turning coherence findings into a gate. That decision belongs to a human reading the report, and promoting a row into a refusal is a separate, deliberate step.
• The application is downstream of the model, not beside it. Coding agents write code against specifications the model produced, into an engine that already carries tenancy, roles, billing and audit. Rejected: generating the application first and reverse-engineering a model from it. That is the round-trip problem, and it is what the sibling principle creation-is-not-a-first-run.mdx exists to avoid.

• You get a product definition you can query, not only read. Which requirement is undecomposed, which document fact is missing, which criterion nothing ships toward: each is a line in a derived report rather than a review meeting.
• Your specifications live in your repository as TypeScript, under version control, and are part of the same history as the code. There is no second system where the model is kept.
• A schema is a commitment. When the model generates a family, the family’s own schema constrains the output, and the family’s validator can reject a value that is schema-valid but internally incoherent. You are not asked to trust a well-formed document that references nothing.
• The report is advice, not a gate. A finding tells you something is stated with nothing behind it; whether that is a defect or a deliberate deferral is your call, and Wildo does not make it for you.