Trilithosby DataSmith AI
Open AItlasOpen Anvil

Anvil · The right upright

AnvilTurn the approved requirement into running software.

Anvil builds, verifies, deploys and releases the application — and the developer keeps full control of how it is built. The result is standard software on mainstream technology that ordinary engineers can maintain.

Open Anvil
Receives
The build contract, from Data Weaver
Recommends
Technology for each part of the stack, with its reasons
Releases
Only after the application is deployed and confirmed running

01From contract to release

The sequence, as a developer meets it.

An AI that built applications on its own would reduce a developer to accepting whatever it produced. Anvil was adopted instead of worked around because it recommends, and the developer decides.

  1. 01

    Receive the build contract

    The contract arrives from Data Weaver with a completeness verdict: an advisory score whose every gap names what to add.

  2. 02

    Validate the intake

    Checked against the real schema. A malformed contract is refused with per-field reasons — never silently reduced to whatever parsed.

  3. 03

    Define the features

    Developer decides

    Each feature carries why it exists, its main flow, exceptions, rules with reasons, screens, endpoints and edge cases. The developer edits the list, and the edited list is what gets built.

  4. 04

    Apply production-readiness doctrine

    Developer decides

    A catalogue of what a production application must also have — audit trail, roles, migrations, no leaked defaults. The developer picks a lean, standard or production profile and confirms or rejects detected traits, with every entry recorded with a reason.

  5. 05

    Recommend technology

    Developer decides

    Anvil proposes a technology for each part of the stack and states why. The developer accepts, changes or replaces any of them before development begins.

  6. 06

    Compose the wireframe

    Every screen authored for this application, in a design system matched to its domain. Modules are checked and repaired; one still defective is a named failure, never quietly swapped for a template.

  7. 07

    Approve the whole application

    Client and developer decides

    The client sees a working preview. Undelivered screens and failed modules block approval unless overridden with a recorded reason. The approved wireframe becomes the implementation contract.

  8. 08

    Bake the contract and plan phases

    The approved design is frozen into the specification. Phases are planned deterministically by dependency, never splitting a module.

  9. 09

    Build through specialist agents

    Developer decides

    Specialist agents build phase by phase in a sandbox, with hard limits on cost, time and iterations. Each phase is dispatched by a person, and never proceeds after an unverified one.

  10. 10

    Verify beyond “it compiles”

    Integration checks, mechanically authored migrations, a runtime crawl, and browser acceptance against the approved wireframe's screens.

  11. 11

    Deploy

    Developer decides

    Never automatic. Known fixes re-applied, secrets injected, repaired on failure, and the application's own readiness check asked for an answer.

  12. 12

    Release once confirmed running

    An application is released only after it is deployed and confirmed running. Where nothing could be verified, Anvil says so rather than showing a green step.

02Production readiness

The system around the feature, not just the feature.

Left to itself, a model builds the feature and not what surrounds it: no audit trail, no roles, no migrations, defaults left in place. Doctrine is Anvil's catalogue of what a production application must also have — and the developer chooses how much of it applies.

  • LeanRecords the ledger and adds nothing — a plain application gets no doctrine text.
  • StandardThe default. Every build starts from a production baseline.
  • ProductionFull doctrine, plus a definition-of-done check before the work counts as done.
  • Detected traits — AI, document processing, multi-tenant, workflow and others — can be confirmed or rejected in both directions. Nothing is added without a recorded reason.

03What Anvil refuses to do

Refusals are part of the product.

Each of these protects a decision a person already made. They are enforced by the platform, not left to good intentions.

  • Build a wireframe that is not approved
  • Dispatch a phase while another is building
  • Proceed after an unverified phase
  • Deploy while any phase is still running
  • Approve with blockers, unless forced with a recorded reason

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.

Data WeaverHand-off inside Trilithos · approved requirement → build contract

For consultants

AItlas

  • Understand the business.
  • Build the strategy.
  • Define what should be built.
Open AItlas

For developers

Anvil

  • Turn the approved requirement into software.
  • Design. Build. Deploy. Release.
Open Anvil