Enso: a discipline for human–AI partnership.

What Enso looks like in an engagement.

You don’t need to adopt a methodology to work with me. Enso is how I run engagements, and it shapes what you receive at each step:

1. Decision and constraints. We agree in writing on the decision, the constraints, and what success means.
2. Written specification. A short document that describes the outcome rather than the implementation, along with the checks that will prove it.
3. Implementation. Your team, a partner, AI tools, or I build against the specification.
4. Acceptance evidence. Tests, reviews, or measurements showing the work meets the specification, checked by someone other than the builder.
5. Updated record. The specification is revised to match what was actually built, so the next decision starts from an accurate picture.

At LifeChef, a team of four used this loop to deliver a HIPAA-aligned intelligence platform in six weeks (the details). The same loop runs through each engagement: every finding in a Technology Assessment carries an acceptance condition, fractional CTO work keeps decisions tied to written specifications, and a Transformation Partnership applies the whole cycle to a build.

The rest of this page sets out the methodology itself, for readers who want the underlying principles.

An operating discipline, not a prompt library.

Enso is a discipline for getting people and AI to do useful work together. It is not a tool, a product, or a prompt library. It is the discipline underneath those things: how work begins, how it is validated, how automation earns trust, and how everything the system builds is kept true to reality.

It runs today as the operating system of a working company stack. On the surface, that means a daily operating picture drawn from calendar, tasks, email, and chat; dashboards generated automatically; and a set of tightly scoped automations. Underneath, which is the part that matters, are model routing that doesn’t depend on one provider, cost metering per service, compression and caching on every traffic path, offline evaluation gates, fail-closed boundaries for each automation, and an autonomous development loop that cannot mark its own work done.

Four system iterations led here. The first three were research and development and were meant to be thrown away. This page describes the discipline that survived them.

This page is current, which is different from finished. Version notes are at the bottom.

The one non-negotiable rule: no spec, no work.

Work begins with a current, accurate, owned description of what is being done. That is the spec. It can describe a role and its operations, or the intent of a single change. Its shape will change as AI capability evolves; the obligation will not. It must be current, accurate, owned, and a description of reality rather than a prediction about it.

If you cannot find or write a current description of what you are doing, you do not have work yet. You have an idea.

A spec constrains outcomes, not implementations. Whoever does the work, whether a person, an AI, or the two together, brings their best current capability to it. We call this scoped freedom, and it matters more every month. Over-specified work stops people and AI from finding better paths; under-specified work produces drift and slop. Enso sits between the two.

The loop

Once a spec exists, all work follows the same cycle: Spec → Execute → Validate → Improve → Spec.

The loop runs in both directions. We check that the work matches the spec, and we also check that the spec accounts for the work. A spec that says nothing about what was actually built is stale, and a stale spec is a failure of the method, not a housekeeping item.

What the methodology binds to, and what it refuses to.

AI capability is the most volatile part of modern work. What AI can do today is not what it will do next month, so a methodology built on assumptions about AI capability goes stale as soon as it is written down.

Enso avoids that by binding to something stable: your current description of what you are doing. Your role, your operations, your decisions, and the intent of the work in front of you. That description is what AI works from, and as AI improves, what it can do with the description improves too, without any change to the methodology.

You do not need to predict AI’s role. You need to keep your description of reality current, and AI will meet it wherever its capability stands.

There is a business argument here as well. Infrastructure bound to descriptions of reality absorbs better models without a redesign. Infrastructure bound to today’s model capabilities loses value as those capabilities move on.

The principles.

Shipping is the measure.

The methodology exists so meaningful work ships continuously, faster, with higher quality and less waste. Any part that doesn’t help shipping hasn’t earned its place. If we slow down to follow the methodology and never speed back up, the methodology has failed.

Real-world outcomes govern.

Shipping counts only when it improves things for the people the company exists to serve. Volume is not value. When speed and outcome conflict, as they sometimes do in clinical and member-facing work, outcome wins.

Bureaucracy is a failure mode.

Documents written to be written. Reviews held to be held. These look virtuous and are not. Process has to justify itself; the people doing the work do not.

Reality outranks doctrine.

When the document, the system, and what we observe disagree, what we observe is the signal. A document that resists reality stops being a description and becomes a fantasy kept alive by force. Enso’s reflex is to question the document rather than reality, and this principle keeps every other principle from being used as a weapon.

Eval is truth, not opinion.

“The senior engineer nodded” is not how we know work is good. Every spec names its success criteria before work starts: automated tests where they apply, rubrics and named thresholds where they don’t. “Working” is not a status. No eval, no done.

Structural enforcement over human review.

If a rule matters, it should be hard to break by accident. People, including the people who write the rules, forget, hurry, and miss things. Structure doesn’t. Human review catches what structure misses, but it does not replace structure.

Drift is a violation, not an inevitability.

Stale documents are the default state of every organization. Enso treats a gap between spec and reality as a failure to be surfaced and owned, not as the weather.

AI surfaces; humans decide.

As the system matures, AI keeps reviewing the documentation, flagging drift, contradictions, and stale material for people to act on. People no longer hunt through a thousand files to keep things current; the system brings the work to them.

Use the least context that can do the work.

AI receives what the task needs, not everything available. This is least privilege applied to cognition, and it is also a quality discipline. Focused context produces focused output. Flooding a model with context produces drift, surprises, and work that is hard to test.

Inherit before you build.

Before scoping a build, confirm that the thing doesn’t already exist in a form you can adopt. We are rarely the first to have a problem. Building is the last resort, and when we build, we build the thinnest thing that closes the real gap.

No status quo.

Tools, documents, views, and processes are questioned regularly, and nothing is grandfathered in. The companion principle is to adopt the latest stable release and stay current. Falling behind the maintained edge is risk dressed up as caution.

Human authority is real, not ceremonial.

A person is not “in the loop” just because they are nearby. Oversight means the practical ability to question, override, pause, and stop, used at the moments that matter. AI may propose, draft, and carry out bounded actions. Accountability for consequential judgment stays with a named human owner, and that line does not move as AI capability grows.

Trust is infrastructure.

Most failures in AI systems are failures of trust more than of technology. A wrong notification or a misread request is a small technical event and a large trust event. Where trust is at stake, the burden shifts toward clarity, consent, traceability, and restraint. We look for ways to move fast that don’t spend trust.

The obligations.

Every artifact and every automation in the system must meet these. They are obligations, not aspirations.

• Currency. Every document is current, being brought up to date, or explicitly deprecated. A deprecated artifact is honest about itself; one that has quietly gone stale is misleading.
• Ownership. No orphan artifacts. If you cannot name the owner, the artifact is outside the methodology and is a liability.
• Evaluability. If success cannot be measured, the description is not complete.
• Traceability. Material work leaves a trail good enough for a reviewer six months later to reconstruct what changed, why, who owned it, and how it was validated. The trail is part of the work, not paperwork about it.
• The 3x rule. Do something three times, then document it and hand the repetition to the system. Once is a fluke, twice is a coincidence, and three times is a pattern that belongs where AI can carry it.
• Governability. Every automation must be discoverable, owned, bounded, observable, reviewable, and stoppable. No stop, no autonomy.
• Reversibility. Being able to stop something is not the same as being able to recover from it. High-consequence automation must be designed so its actions can be undone. No rollback, no high-consequence autonomy.

The eight core rules.

These are the anchors, the phrases worth carrying through any change in tools, models, or context:

1. 01No spec, no work.
2. 02No check, no build.
3. 03No owner, no system.
4. 04No eval, no done.
5. 05No trace, no trust.
6. 06No stop, no autonomy.
7. 07No rollback, no high-consequence autonomy.
8. 08No ungovernable work.

When Enso is failing.

A methodology that can’t describe its own failure modes shouldn’t be trusted with anyone else’s. Enso is failing when specs and operations have drifted apart and nothing catches it; when questioning has become the work and shipping has slowed; when review meetings happen but nothing changes; when the core rules are quoted to enforce conformity instead of to test work; when people comply without trusting; when documentation is produced for the methodology’s sake; or when the methodology itself has stopped changing.

Noticing these is not a violation. It is the signal that the methodology needs revising, and the reflex is to question Enso, not the people doing the work. The loop applies to the methodology too. The circle never closes.

Discovered, not designed.

Enso was built from operating experience across four system iterations. Only afterward did we notice how closely its mechanics match a line of well-established work: the environment-over-willpower idea in Atomic Habits (our structural enforcement), jidoka and kaizen from the Toyota Production System (our fail-closed gates and ongoing improvement), Google SRE’s approach to toil (our 3x rule), the delivery research in Accelerate (shipping as the measure), shared awareness with empowered execution from Team of Teams (our operating picture and scoped freedom), the Unix habit of composing small trusted parts (our unit-and-orchestra architecture), and trusted capture from Getting Things Done (our task pipeline).

None of these shaped the design, but all of them support it. Two disciplined processes arriving at the same mechanics independently is stronger evidence than one copying the other, and it is a good reason to think these conventions carry real weight rather than following fashion.

The principles are here. The installation is the work.

Enso has three more layers, each changing on its own schedule: Doctrine (the current operating model: spec modes, validator patterns, risk tiers, and escalation), Implementation (the current tooling: agent runtimes, hooks, templates, evaluation harnesses, and packaged workflow kits), and the Quickstart (what to do on Monday morning).

They aren’t published. That isn’t secrecy; they are perishable and specific to each company. The methodology binds to each organization’s own description of its work, so there is no generic install. Every deployment involves drawing out that description, calibrating trust, and judging where the boundaries go, and the answers differ from company to company. A template filled in against someone else’s reality produces exactly the drift this methodology exists to prevent.

If you want the installed version, with bounded tools, outputs you can trust, and workflows that run with one click, the conversation starts with a description of how your team works day to day.

• September 2026: added the engagement overview at the top of the page and edited the text for clarity. The principles and rules are unchanged.
• Version 2, July 2026: rewritten for production use after the fourth system iteration.
• Version 1: first published earlier in 2026.

Maintained by Jay Leon, Vitasphere. This page changes when reality does.