How it works
One journey.Twenty-three stages.
The journey starts when a consultant opens an engagement by typing the client's name. It ends when a developer releases an application confirmed to be running. Here is every stage in between, who owns it, and where a person decides.
- Stages
- 23, across three platforms
- Hard gates
- 8 points where the platform stops until a person decides
- Ends
- Only once the application is confirmed running
01The journey
From conversation to confirmed running application.
Select any stage to see what enters it, what happens, what leaves, and who owns it.
Create engagement
What enters
A company name
What happens
AItlas extracts a company profile. Where two companies share a name, it asks which one is meant rather than choosing.
What leaves
An engagement record with a starting profile
Client conversation
AItlas
1Create engagement
Enters: A company name
Happens: AItlas extracts a company profile. Where two companies share a name, it asks which one is meant rather than choosing.
Leaves: An engagement record with a starting profile
Owner: Consultant · Disambiguation, when names collide
2Intake dossier
Enters: The client's annual report or website
Happens: Three ingest passes: the client's own site, a full company profile, then qualitative evidence — pain points, goals, systems, competitors — with hypotheses kept separate from evidence.
Leaves: A populated dossier, a list of hypotheses, and questions to ask the client
Owner: Consultant · Identity check; hypotheses adopted only by explicit action
3Company research
Enters: The dossier
Happens: Research grounded in real sources.
Leaves: A research brief
Owner: Platform
4Competitive landscape
Enters: The research brief
Happens: Grounded competitor analysis and positioning.
Leaves: A competitive landscape
Owner: Platform
5Strategy map
Enters: The competitive landscape
Happens: Strategic moves, with the reasoning retained alongside each one.
Leaves: A strategy map
Owner: Platform
6AI technology atlas
Enters: The strategy map
Happens: A diagnosis, then a catalogue of recommended AI capabilities — together with anti-recommendations: the things not to do.
Leaves: A capability catalogue
Owner: Platform · The consultant reviews, edits and consolidates
7Go-to-market plan
Enters: The technology atlas
Happens: A phased delivery plan and a move-by-phase matrix.
Leaves: A go-to-market plan
Owner: Platform
8Application portfolio
Enters: The capability catalogue
Happens: Capabilities are clustered into standalone, buildable applications.
Leaves: A proposed application portfolio
Owner: Platform · The consultant curates the grouping
9Application specification
Enters: One curated group
Happens: Five dependent passes — entities, API contract, features, narrative, screens — each reading what the previous one wrote.
Leaves: The application requirement in prose, and the structured specification behind it
Owner: Platform · The consultant reviews conflicts and can correct or delete claims
10Hand-off decision
Enters: The approved application
Happens: The consultant decides this application is ready to build.
Leaves: An application approved for hand-off
Owner: Consultant · The first hard gate
Data Weaver
11Data Weaver
Enters: The approved requirement and specification
Happens: Read and validate → derive requirements, narrative and constraints → structure entities, routes and features → prepare the reconciliation report → hand off.
Leaves: The build contract, and a recorded push
Owner: Platform · None of its own — the decision was made at stage 10
Anvil
12Build intake
Enters: The build contract
Happens: Validated against the real schema. A malformed contract is refused with reasons rather than silently reduced.
Leaves: A build intake, ready for planning
Owner: Platform
13Feature review
Enters: The delivered feature set
Happens: The developer edits the list. When the list is regenerated, those edits are treated as hard constraints.
Leaves: The approved feature list — this is the build contract
Owner: Developer · The developer approves the feature list
14Doctrine
Enters: The specification and its detected traits
Happens: The developer picks a production-readiness profile and confirms or rejects each detected trait. The consequence of each choice can be previewed before it is committed.
Leaves: Readiness selections, with a recorded reason for every entry
Owner: Developer · The developer sets the readiness profile
15Technology selection
Enters: The features and the technology catalogue
Happens: Anvil recommends a technology for each part of the stack and states its reasons. The developer accepts, changes or replaces any of them.
Leaves: The chosen stack
Owner: Developer · The developer chooses the technology
16Wireframe composition
Enters: Specification, readiness selections and stack
Happens: The model authors every screen. Each module is checked and repaired against findings; a module still defective is a named failure, never a silent substitution.
Leaves: A composed, versioned wireframe
Owner: Platform · Pause, retry and stop are available throughout
17Wireframe approval
Enters: The composed wireframe
Happens: The client sees a working preview and approves it. Undelivered screens and failed modules block approval unless explicitly overridden with a recorded reason.
Leaves: The frozen UI implementation contract
Owner: Client and developer · The client and developer approve the preview
18Contract bake
Enters: The approved wireframe
Happens: The stored design system and per-screen digests are frozen into the specification, and the readiness selections lock.
Leaves: The complete build contract
Owner: Platform
19Phase planning
Enters: The baked contract
Happens: Modules are clustered deterministically into phases by dependency, with the screens that write an entity claiming it first.
Leaves: An ordered phase plan
Owner: Platform
20Phased build
Enters: One phase
Happens: Specialist agents build against a shared workspace. Static checks, migrations, a runtime crawl and browser acceptance run for each phase.
Leaves: A verified phase
Owner: Developer directs · Every phase is dispatched by a person
21Deploy
Enters: The delivered build
Happens: Known fixes are re-applied, secrets injected, containers started, repaired on failure, and readiness confirmed.
Leaves: A running application
Owner: Developer · Deployment is never automatic
22Publish
Enters: A running application
Happens: The application is given a public hostname.
Leaves: A reachable address
Owner: Developer · Opt-in, per request
Publishing is available through Anvil's API today; a publish control in the Anvil interface is planned.
23Release
Enters: A confirmed application
Happens: Released only after it is deployed and confirmed running.
Leaves: Delivered software
Owner: The delivering firm
Confirmed running application
02Architecture, simplified
Three platforms. One path through them.
Data Weaver is not a separate service to operate: it is a component inside AItlas with its own contract, stages, tests and failure states.
- ClientThe conversation, the client's own material, and the approvals only the client can give.
- AItlasBusiness understanding: the engagement, five analyses, and the application requirement.
- Data WeaverRequirement → developer-facing specification, in five narrated stages.
- AnvilBuild → verify → deploy → release, phase by phase.
- Running applicationStandard software on mainstream technology, confirmed running.
Across every layer
Model layer
Nine AI providers behind one configuration setting, with behaviour gated on each model's capabilities rather than its name. A self-hosted model can be attached.
Human approvals
Defined points where the platform stops and waits — hand-off, features, readiness, technology, preview, every phase, deploy.
Data
One structured document per engagement that every analysis writes into. An engagement or build that is not yours is not found.
Observability
Live, stage-by-stage progress in both platforms; failures kept on the record rather than deleted; absence reported as absence.
Infrastructure
Model-authored code runs in isolated sandboxes. Either platform can run inside a client's own infrastructure.
Enter the platform
Two doors, one structure.
Consultants work in AItlas. Developers work in Anvil. Data Weaver carries the approved requirement from one to the other.
For consultants
AItlas
- Understand the business.
- Build the strategy.
- Define what should be built.
For developers
Anvil
- Turn the approved requirement into software.
- Design. Build. Deploy. Release.