The context layer for AI-assisted development
Every layer,
one reference graph.
Every screen, contract, state model, table and decision in the delivery package — indexed, cross-referenced, and checked against each other. The requirements a workshop produced, the decisions taken about them, and every artefact derived from those decisions, in one place that refuses to contradict itself.
Requirements → decisions → contracts → data model → screens → handoff
Understands
your context
Schema & contracts · Documentation
Data & APIs · Requirements · Decisions
Developer
in the loop
Collaborate.
Refine. Iterate.
Production-ready
software
Built for
what's next
Tested · Documented · Secure
Scalable · Ready to deploy
Counted from the package this instance serves, at design 87% and build 33%.
01 / What Adam is
01 / What Adam isA contract-first package that refuses to contradict itself.
Nothing merges that disagrees
A screen cannot call an operation that does not exist. An operation cannot name a table stored nowhere. A state model cannot anchor on a schema with no values. A flow cannot step through a screen that was deleted.
Nothing holds a copy of anything else's truth
A screen names an operation; the operation resolves against the contracts; the contract resolves against the schema; the schema resolves against the relationship graph.
Every artefact is regenerated where it can be
The boards come from the screens, the schema reference from the contracts, the relationship graph from both. A hand-maintained copy is a copy that goes stale, and this package has been bitten by that three times.
02 / The journey — before the derivation
02 / The journey — before the derivationFrom a room full of requirements to a decision the package can hold.
Seven steps happen with people in the room. Each one leaves something behind that Adam can read — a parsed pack, a minute, an ADR, a signed verdict — so the next step starts from the record rather than from memory.
Ready for build
03 / The derivation chain
03 / The derivation chainOne command, in dependency order.
After any change to the contracts, screens, flows, states or events, everything downstream is rebuilt. The order matters — the domain closure reads the lineage, and the status reads the closure. Pick a step to see what it writes and why it exists.
04 / Reading it back
04 / Reading it backFour layers, one switch
Contracts sit near the middle deliberately: the API is the join between the outer two, and every other layer is drawn by resolving against it.
And read by the assistant writing the code
Nineteen tools over MCP answer from the same index the viewer draws: one screen with its operations and states, one flow with its branches, one table with its columns and migration, one ADR in full, or the file behind any of them.
The package itself stays read-only from the bridge. One tool records that a work package is about an artefact; one saves a ticket and what it touches as local files; and a status, % done or comment reaches OpenProject only after the developer has seen the change and said yes.
See it against your own delivery package.
Adam reads the package straight from the repository. Nothing is uploaded, and nothing leaves the machine it runs on.
Access is by invitation. Ask whoever runs the package to send you one — an invite works once and expires after seven days.