Leverge Design · private preview
A brief, your existing documents and one discovery pass become thirteen deliverables — architecture, ERD, backlog, BRD, threat model, SOW — generated from a single versioned context, so the diagram, the document and the estimate cannot disagree.
Experience
API & Services
AI & Intelligence
Data platform
AI Assistant
Scoped to Architecture Diagram
Every action proposes a patch. Nothing changes until you accept it.
What is AI solution design?
AI solution design is the step between "we should build this" and "engineering can start": turning a brief, a stack of documents and a discovery conversation into an architecture, a data model, a backlog and a statement of work that agree with each other. Leverge Design does it from a single versioned Solution Context — one structured object holding the solution identity, six architectural layers and every decision taken during discovery. Thirteen deliverables generate from that object rather than from free-floating prompts, so the diagram and the narrative cannot disagree, every field records whether a person or the model wrote it, and changing one field marks exactly the deliverables that read it as stale.
The problem
Not because architects are slow, but because the inputs are scattered, the artefacts are disconnected from each other, and nothing in the process knows what is still missing. The result surfaces during implementation as rework, and by then it is expensive.
A business case as a PDF, a PRD in Confluence, a workflow drawn in someone’s slide deck, and the two constraints that actually shape the architecture said out loud in a call. Nothing reconciles them, so the architect reconciles them by reading everything twice.
Days of reading before anyone can draw a box
The picture is drawn in one tool and the specification written in another. The moment either is edited they describe different systems, and nothing in either file knows the other exists.
Rework found in sprint three
Deployment target, data residency, autonomy boundary, identity model. These are answerable in the first hour and usually surface after the estimate has been sent, because nothing was tracking which fields were still empty.
An estimate built on assumptions nobody wrote down
A number produced from a similar-sounding project last year, with no backlog underneath it and no way to show how it was reached when the client pushes back on it.
Margin discovered at delivery, not at signature
A reviewer asks why the design assumes an eight-year retention period and there is no answer beyond "someone said so", so a settled decision reopens and the discovery call runs again.
Every review reopens closed decisions
The proposal was written to win the work, not to build from. The engineering team receives it, finds it unbuildable as specified, and reconstructs the design from scratch with the client on the phone.
Presales work paid for twice
How it runs
Each step arrives pre-filled from the one before it, so the job is refinement rather than authorship. The arc back to step two is the part that matters after the first pass: the context stays editable, and the deliverables know when they no longer match it.
A paragraph of intent plus whatever documents exist. Each one is extracted, classified, summarised in a line, and indexed — and the raw extracted text stays visible, so you can see exactly what the model is reading.
Solution identity and six architectural layers arrive pre-filled from the description and the documents. Every field is stamped with its origin, so an AI-written value never quietly becomes a stated fact.
Blocking gaps and quality suggestions are listed separately, and five to eight generated questions each name the context field they resolve. The recommended option carries the reasoning behind it and stays reversible.
Pick the deliverables you need. They generate in dependency order — architecture before the threat model, backlog and BRD before the SOW — and stream in as each one completes, with the credit cost estimated before you commit.
A cross-deliverable review scores build-readiness, the backlog becomes an effort and cost range, and the package exports as Markdown or a print-ready document — or pushes into GitHub as milestones and issues.
The intake
Every field below arrives pre-filled from your description and documents, and is marked with whether the model wrote it or you did. The blocking ones gate the next step; the rest shape the deliverables that read them.
Blocking Thirteen of the thirty-two fields gate the next step. The rest are optional, and every one of them arrives pre-filled from your description and documents.
Solution identity Step 2 · 11 fields
Step 3 · Architectural layers · 21 fields
Experience & Access
Intelligence & AI
Services & Integration
Plus a structured external-systems table: system · direction · criticality · protocol.
Data & Storage
Platform & Runtime
Security & Trust
Capabilities
Three properties do the work: the intake is grounded in your own documents, every deliverable comes out of one structured context, and the package stays alive after it is generated.
Each upload is extracted (with an OCR path for scans), classified as a business case, PRD, RFP or workflow reference, summarised in one line, and indexed for retrieval. The extracted text is shown back to you per document, because a model reading a garbled table is a failure you want to see at upload, not in the architecture.
A value written by the model is marked as a prefill; a value you changed is marked as yours. That distinction is what makes the screen safe to put in front of a client — the difference between "the system inferred this" and "you told us this" stays visible instead of collapsing into one confident paragraph.
Required recommendations name the field and what specifically is thin — a stated objective with no baseline, a retention period missing under GDPR. Suggestions are the quality tier. Each one can be applied as a patch, dismissed, or asked about, and applying it writes the field.
Each generated question cites the context field it resolves, and the recommended option carries the reason it is recommended — "the ERP and the banking gateway already run in that region, so co-locating removes a hop from the payment path". Answering writes back into the layer field the question was asked about.
Step 2 · Solution Identity Prefilled from 3 documents
Required before generation Retention & Residency
Financial records typically carry a 7–10 year statutory retention requirement, and GDPR is selected. State retention period and data residency before the architecture is generated.
Apply Dismiss Ask
Step 4 · Question 1 of 6 Resolves Platform → Cloud target
Which cloud environment should the solution be deployed to?
The architecture diagram is stored as zones, nodes, edges and trust boundaries — validated data, not a blob of Mermaid. Mermaid and SVG are renderings of it. That is what makes a diagram editable node by node, diffable between versions, and exportable to more than one format without regenerating it.
Every deliverable that has two faces generates both in one pass from one model. The description cannot describe a component the diagram does not contain, which is the single most common way a design package becomes untrustworthy between the review and the build.
The microservice decomposition, data flow, API contract and threat model generate after the architecture they depend on; the SOW generates after the BRD and the backlog. A partial failure fails one deliverable, never the batch.
Each deliverable carries a credit estimate, generators run on a model tier chosen per deliverable, and every call records its token usage against one rate card. "What did this proposal cost us to produce" has an actual number behind it.
Experience
OIDC · REST
Private VPC — EU · Zero-trust zone
API & Services REST · rate-limited
AI & Intelligence queue-fed · scalable
Unified data platform EU region · encrypted at rest
adapters only — no service calls the ERP directly
Integrations
Each generator declares the context it consumed. Edit retention and residency, and the architecture, threat model and NFR spec are marked stale while the user journey stays current — with a regenerate action and a view of what changed. Staleness that marks everything is staleness nobody acts on.
Deliverables keep their own history: generated, revised by the assistant, regenerated after a context change. You can see which context revision a version was built from, which is the difference between an artefact and a screenshot of one.
It proposes a patch to the model behind the current deliverable — not a chat about your project. Quick actions are named patches: simplify the architecture, add monitoring, add a security zone. Nothing is applied until you accept it.
Every deliverable is generated independently, so nothing checks that they agree — until a review pass reads all of them together and reports consistency issues, coverage gaps and a build-readiness score. A backlog missing a story for a component the architecture names is the kind of thing it catches.
The package exports as Markdown or a print-ready document with the diagrams still vector, and the backlog pushes into your own GitHub repository as one milestone per epic and one issue per story, acceptance criteria intact. Your token is used for that request and never stored.
Architecture Diagram is stale context rev 8
Retention & Residency changed after this deliverable was generated. The deliverables that never read that field stay current — staleness follows the dependency, not the clock.
Regenerate Show what changed
Version history
Package review 82/100 build-ready
What you get
Pick the ones the engagement needs. Diagram deliverables carry a narrative generated from the same model; document deliverables carry the tables and the numbers. Every one of them pins the context revision it was generated from.
Swimlane flow of the automated process with the human checkpoints marked, plus the step narrative.
Capability map of what the solution does, grouped into the functional areas it is delivered in.
Container view: zones, services, the AI tier, data platform and trust boundaries, with the design narrative.
Service decomposition with responsibilities and the contracts between them.
Entities, relationships and cardinality, with the schema narrative alongside the diagram.
How records move between services, stores and external systems, and where they cross a boundary.
A hierarchical backlog with story points, MoSCoW priority and acceptance criteria per story.
The formal business requirements document, generated from the whole context rather than a template.
Journey map per persona, drawn from the roles and journeys captured in the experience layer.
Performance, availability, scalability and operability targets tied to the constraints you stated.
Threats against the generated architecture, with mitigations mapped to the security layer.
Endpoints, payloads and error semantics for the services the architecture defines.
Phased plan, effort, milestones and assumptions, generated after the BRD and the backlog it prices.
Governance and traceability
The question that decides whether a generated design is usable in a regulated business is not whether it looks right — it is whether anyone can reconstruct where it came from. Provenance per field, an immutable event chain, and the compliance answers captured before generation are what make that reconstruction possible.
GDPR, HIPAA, SOC 2, PCI-DSS, DPDP and ISO 27001 are picked during intake, alongside retention and residency, the authentication and authorisation model, secrets and key management, audit requirements, and where a human stays in the loop. Those answers are in the context before a single deliverable generates, so the architecture is shaped by them rather than reviewed against them afterwards.
Each generation, revision, applied recommendation and export writes an event that stores the hash of the event before it. The chain recomputes from genesis, so a gap, a reorder or an edited row is detectable rather than a matter of trust. It is the same audit discipline the agent runtime uses — one mechanism, not a second one written for this module.
The project, the user, the step and its data classes are passed to a policy check before each deliverable generates. A deny fails that deliverable with the reason attached and lets the rest of the batch continue, rather than proceeding quietly. The interception point is real even where the policy set is still simple.
This is the honest boundary. The module makes the design defensible — what was decided, from what input, by whom, at which revision. Enforcing policy on the deployed solution at runtime is a different job, done by the agent runtime that executes it, and no claim here should be read as covering it.
Who it is for
Run the discovery call inside the artefact instead of taking notes to reconstruct afterwards.
Start from a populated architecture and spend the time on the decisions, not on the first draft.
Hold every initiative to the same structure, with the security and data layers filled in before sign-off.
Receive a backlog with acceptance criteria and an architecture that matches it, not a slide deck.
Turn an idea into epics, an effort range and a phased plan in one pass, with the assumptions listed.
See what a proposal cost to produce, what it assumes, and where the design is still thin.
Limits
Stated here rather than discovered in a demo. The boundaries are deliberate, and the four integrations still waiting on verification against a live instance are named rather than implied.
Design runs inside the Leverge platform and is being used on our own engagements first. There is no self-serve signup, no plans, and no client share links yet — access happens through a walkthrough and a conversation about your first project.
This is not a project-management tool and does not try to become one. Markdown, print-ready PDF, Mermaid and a GitHub push are live today. Jira, Linear, Confluence and Notion are built to each API and are waiting on verification against a live instance; DOCX and XLSX are not built yet.
It does not generate the application. The boundary is a package an engineering team can build from — architecture, data model, contracts, backlog, plan — and it ends there deliberately, because a code generator would make the design a by-product of whatever it could compile.
Generators are grounded in your context and reviewed cross-deliverable, and they still produce work that a person has to accept. Every node traces back to a context field precisely so that judgement is possible — the review scores build-readiness, it does not certify a design.
Next Step
A working session, not a demo: we run your own initiative through the intake, generate the package in front of you, and you keep the export whether or not anything follows. Bring whatever documents exist — a business case and a rough brief is enough to start.