Notes from the AI cloud

We wrote down how business software should be built on DODIL, then handed the method to agents that had never seen it and played the customer ourselves. One day: a signed-off design with 26 decisions, an app with 36 tests named after the requirements, ten screens, three change requests with impact statements, and three platform faults found by the tests. Here is the transcript-level account, including the two places the method itself failed and what we changed.

A customer says 'we need an app'. What follows decides whether they get their business or ours: the roles, the stories with their acceptance criteria, the records and who owns them, written down and signed off before any code — then generated, tested per story, and changed later without fear. This is the lifecycle an agent follows, why each phase exists, and what it produced when we ran it end to end with a customer who had never had a system.

The build phase, once the design is signed off: what ships in the CRM package, which file answers which user story, the five rules that decide whether a customer can live with the result, and the parts that are configuration rather than code — stages, discount thresholds, quote validity, loss reasons. Read the module first; read this when you are ready to generate someone's system.

Every DODIL tutorial builds an engine and stops at shown-as-code. This is the supported last mile, and it is git-driven: push to a DODIL repo, the forge runs your .github/workflows/ci.yml with the registry credentials already injected, the image lands in registry.dodil.io, and an in-repo .dodil/deploy.yaml applies it to an Ignite app — runtime credentials resolved from the repo's secret store at deploy time, end-user login done by the gateway, neither one written by you. One org, one bill, one auth context, no GitHub, no Docker Hub, no external CI.

Every app you build on DODIL serves two kinds of caller: business users who log in (sales reps, customers, guests) and platform principals (service accounts, CI, other services) that call it machine-to-machine. On DODIL that is a config decision, not an auth library. Attach a dodil-appid pool to an Ignite app and the per-cluster gateway runs the whole browser login — PKCE S256, an AEAD-sealed host-only session cookie, single-flight refresh — then injects X-Dodil-User, X-Dodil-User-Jwt and X-Dodil-Auth-Source into your request. The app ships no auth code. Platform callers keep working alongside, because the model is additive. And when you are NOT behind that gateway, you verify the pool's EdDSA JWT yourself against its JWKS with iss AND aud mandatory.

Your app on DODIL knows who the user is — now it needs to know what they can do. A rep sees only their deals; an approver can approve invoices. The usual answers are a policy server (OPA, a permissions microservice) you call on every request, or authz logic smeared through the app. dodil-appid does RBAC in the token: a per-pool role catalog maps roles to resource:action permissions, a user's roles expand into a permissions claim on their JWT, and the app checks permissions locally with zero round-trips. Behind the Ignite gateway that token arrives already verified in X-Dodil-User-Jwt, so the app reads permissions off an injected header and verifies nothing. Tenants add per-subsidiary roles and tenant-pinned tokens — the ERP layer. And the two-plane rule holds: appid says who and what-role; the app filters rows by sub via its own service account, because bucket RBAC can't do per-row authz.

Every DODIL tutorial builds an engine and stops at shown-as-code. This is the supported last mile, and it is git-driven: push to a DODIL repo, the forge runs your .github/workflows/ci.yml with the registry credentials already injected, the image lands in registry.dodil.io, and an in-repo .dodil/deploy.yaml applies it to an Ignite app — runtime credentials resolved from the repo's secret store at deploy time, end-user login done by the gateway, neither one written by you. One org, one bill, one auth context, no GitHub, no Docker Hub, no external CI.

Every app you build on DODIL serves two kinds of caller: business users who log in (sales reps, customers, guests) and platform principals (service accounts, CI, other services) that call it machine-to-machine. On DODIL that is a config decision, not an auth library. Attach a dodil-appid pool to an Ignite app and the per-cluster gateway runs the whole browser login — PKCE S256, an AEAD-sealed host-only session cookie, single-flight refresh — then injects X-Dodil-User, X-Dodil-User-Jwt and X-Dodil-Auth-Source into your request. The app ships no auth code. Platform callers keep working alongside, because the model is additive. And when you are NOT behind that gateway, you verify the pool's EdDSA JWT yourself against its JWKS with iss AND aud mandatory.

Your app on DODIL knows who the user is — now it needs to know what they can do. A rep sees only their deals; an approver can approve invoices. The usual answers are a policy server (OPA, a permissions microservice) you call on every request, or authz logic smeared through the app. dodil-appid does RBAC in the token: a per-pool role catalog maps roles to resource:action permissions, a user's roles expand into a permissions claim on their JWT, and the app checks permissions locally with zero round-trips. Behind the Ignite gateway that token arrives already verified in X-Dodil-User-Jwt, so the app reads permissions off an injected header and verifies nothing. Tenants add per-subsidiary roles and tenant-pinned tokens — the ERP layer. And the two-plane rule holds: appid says who and what-role; the app filters rows by sub via its own service account, because bucket RBAC can't do per-row authz.

We wrote down how business software should be built on DODIL, then handed the method to agents that had never seen it and played the customer ourselves. One day: a signed-off design with 26 decisions, an app with 36 tests named after the requirements, ten screens, three change requests with impact statements, and three platform faults found by the tests. Here is the transcript-level account, including the two places the method itself failed and what we changed.

A customer says 'we need an app'. What follows decides whether they get their business or ours: the roles, the stories with their acceptance criteria, the records and who owns them, written down and signed off before any code — then generated, tested per story, and changed later without fear. This is the lifecycle an agent follows, why each phase exists, and what it produced when we ran it end to end with a customer who had never had a system.

The build phase, once the design is signed off: what ships in the CRM package, which file answers which user story, the five rules that decide whether a customer can live with the result, and the parts that are configuration rather than code — stages, discount thresholds, quote validity, loss reasons. Read the module first; read this when you are ready to generate someone's system.

As of June 22, 2026, the DODIL AI cloud is open for alpha. Sign up free and start building on DataK3, Ignite, Models, and Scriptum — with the CLI or by prompting an agent.