Data Weaver · The lintel
Data WeaverThe intelligence that closes the gap.
Data Weaver reads the application requirement the client approved — written in business language — and derives the developer-facing build contract. Previously a developer who was not in the meetings wrote that. Now nothing is retyped and nothing is reinterpreted.
- Reads
- The approved requirement and specification from AItlas
- Delivers
- The build contract, into Anvil
- Where it runs
- Inside Trilithos, started by the consultant's push from AItlas — there is no separate app to open
01Five stages
Read. Derive. Structure. Prepare. Handoff.
The hand-off narrates itself stage by stage, with the real facts it derived. A stage reports done only after its work has returned.
Read
What it does
Validates the request and ownership, requires a non-empty requirement, refuses a malformed specification with a reason, and mints stable feature identifiers.
What it reports as it goes
- Application name
- Capability count
- Requirement length
- Whether a structured specification is present
02A platform, not an integration
The hand-off was always work. Naming it made it accountable.
An API connection moves data. Data Weaver is responsible for what the data means on the other side.
- 01
It can be watched
The hand-off narrates itself stage by stage, with the real facts it derived — entities, requirement count, feature count — as they are produced.
- 02
It can be held to a standard
Because it is a component, it has a contract, tests, failure states, and a boundary it states out loud.
- 03
It can refuse
A hand-off that cannot be completed honestly fails at a named stage with the real reason, rather than delivering something plausible.
03What crosses the lintel
Everything the developer needs. Nothing the client did not approve.
Every optional element is left out rather than sent empty: an empty specification would read as “this application needs nothing”.
- RequirementsPer-capability build requirements, matched by name and carried verbatim. A capability without one is omitted — never fabricated.
- Named entitiesEntities with typed fields, the business meaning of each field, and the relationships between them.
- RulesThe non-functional constraints the requirement sets. A stored value always wins, so the compliance boundary never depends on when the application happened to be planned.
- SpecificationThe resolved specification and, when one was written, the application narrative — brief, actors, architecture, lifecycle and scenarios. Absent content is omitted, not sent empty.
- FeaturesEach feature with a stable identifier minted from its title — the same across re-pushes — so two features can never silently become one.
- Deployment configurationThe application kind — web, AI or hybrid — and any existing system it extends.
The boundary it states out loud
“Stack, database and environment are selected in Anvil.”
Data Weaver derives what the requirement determines. It does not choose technology — that decision belongs to the developer, on the other stone.
04When it cannot complete honestly
It fails at a named stage, with the real reason.
A failed hand-off names the stage that failed, shows the real error, and offers a retry. It never delivers something merely plausible.
- When
Anvil refuses the contract
The push is still recorded as failed, the hand-off stage is named, and the real reasons pass through verbatim.
- When
The requirement is empty or the specification malformed
Refused at Read, before any work, with a clear reason — not discovered later at the build.
- When
The connection is interrupted
The consultant is told the hand-off was interrupted before Anvil confirmed it. Never a silent hang.
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.