Why
Every Elevator project starts with a Target — a strategic outcome the team is working toward. "Achieve a Gibraltar PayFac licence by Q3."
Targets are the only primitive that names a business goal. Everything else exists to serve them.
Decomposition
The Target tells you why. The regulator's submission template and guidance — ingested as Documents — tell you what shape the answer must take.
The integrator reads them, maps the template's structure to Sections, and atomises the regulator's text into Requirements: verifiable claims that must hold for the application to land. One Requirement can sit in many Sections; the same claim often turns up in different parts of the document.
Knowledge in
Alongside the regulator's guidance sit the team's own Documents — policies, prior submissions, the business plan as it stands, KYC procedures, whatever has been uploaded. Plus AI-generated summaries for fast retrieval.
A regulator only accepts evidence that lives in a formal document. The application is built from these and nothing else.
Grounding
Evidence is the bridge between source and claim. When a Requirement is supported by something in a Document, an Evidence entry is created — with a quoted fragment, a confidence tier (high / medium / low), and a status.
Two Requirements just turned green. They're closed.
The gap
Some Requirements have no support in any Document. Rather than guess, the integrator surfaces a Question — a specific, scoped ask that blocks drafting until answered.
The integrator never authors truth. It asks.
The human loop
Users respond. Their words land in a UserInput queue and get stamped onto the relevant Question — verbatim, never re-authored as the integrator's own proposal.
That answers the Question, not the Requirement. A regulator won't accept a chat response as evidence on its own — what it unlocks is drafting. The Requirement was blocked; now it's ready.
Composition
Once a Section's Requirements are ready — supported by Documents, or unblocked by user responses that drafting can absorb — a Draft composes them into prose.
This is where ad-hoc answers become formal application content. The Draft, once approved, is the policy or business-plan section the regulator reads. DraftFeedback captures the redlines on the way there.
External review & cross-cutting
When the team sends a draft to outside counsel, the comments come back as a ReviewCycle — split into individual ReviewItems for reply and amendment.
Cross-cutting concerns sit alongside: Issues thread observations across multiple primitives; References anchor external context (URLs, tooling) to whatever they bear on.
Composition & submission
Every Draft is approved. The compiler stitches them together — section by section, in template
order. Some Documents ride along verbatim: audited accounts,
articles of incorporation, signed agreements — attached to the package as-is rather than
rewritten into prose. The whole build is stamped with a CompilationMeta:
timestamp, content hash, changelog since the last build.
The Target's lifecycle transitions from active to
completed. The application ships. The integrator stays alive — regulator
follow-ups land as new user_inputs, Issues open against the submitted text,
the audit trail is intact for whatever comes next.