Principles
Why Wildo is built this way
Why Wildo is built the way it is, at research level. One file per principle. Each states the principle in one sentence, the problem it answers, what it rules in and out, the mechanisms in the framework that embody it, and what it means for someone building with Wildo. Every mechanism named carries a path in an Evidence table.
Twelve principles
- A claim about the system names the target that proves it, or it is not a claim — Wildo treats a statement about what the framework does as a measurement, not an opinion. A guard is proven by a request that reaches it, a capability is shipped when a running application uses it, a checker is trusted when it has been…
- Build on shared behavior — A new business application needs its own workflows. It also needs people to sign in, records to stay within the right organization, and operations to follow access rules. Those concerns return in project after project.
- Keep accepted work in the project's history — Product definitions and application code belong in the repository. Git gives the team a shared way to review changes, accept them and understand how the product evolved.
- Keep business terms consistent, too — Repetition also happens in small decisions. A task status may appear in a form, a filter, an API response and a business rule. If each place defines its own list, they can disagree while each looks correct in isolation.
- Keep the method useful after the first release — An application keeps changing after it first works. Wildo's playbooks can revisit product definitions and implementation plans using the application that exists now, rather than treating creation as a one-time sequence.
- Protect the boundary. Keep a way to recover. — A refused action should protect the application without leaving its administrators stranded. Wildo pairs sensitive access rules with specific recovery operations, so support can correct an exceptional situation without opening every…
- Structure the product richly and the process minimally, because a wrong schema refuses and a ceremony becomes the subject — Wildo puts its structure into the thing being built and keeps it out of the way the thing is built. The product model is typed down to the reference: every family has a schema, a validator, and a cross-family report.
- Teach the framework through its contracts and methods — An agent working in an application needs a usable account of the framework: what it provides, how to extend it and which connections a change affects. That guidance should work without requiring a framework checkout.
- The product is a structured model of the business; the application is a projection of it — Wildo does not start from a blank repository and a prompt. It first builds a model of the business: a vision brief, a market snapshot, requirements, a roadmap, a domain plan, a build plan, a compliance posture.
- Use AI for judgment. Make the checks explicit. — AI helps explore a product, write its definitions and implement its behavior. Wildo connects that work to structured contracts, repeatable checks and reviewable changes, so a convincing answer is the beginning of evaluation rather than its…
- Wildo is assurance-ready by construction: the control, its marker and its evidence are one grep apart — Wildo treats auditability, access control, privacy and evidence as properties of the engine rather than as a programme bolted on before an audit.
- Wildo narrows its world to B2B SaaS and corporate internal tools, because a knowable domain is what makes a methodology writable — Wildo is not a builder for any software. It is a builder for one kind of software: the application a company sells to other companies, or runs for its own staff.