Meaning before generation
A Blueprint is the version of your product that outlives its stack.
A Blueprint names the things a business already talks about: customers, invoices, approvals, the pages people work in, the rules that must hold. It is written to be read by the people who own those rules, not only by the engineers who will implement them. Everything downstream works from it: which capabilities get reused, what validation checks, what generation emits, what a release records. A version is published once, compared against its predecessor, and approved by the people policy names before anything is built from it. Code generation is the fifth of six layers here. The blueprint layer is the second of the six, and nothing below it starts until the Blueprint exists.
Starting from code loses the reason
Write the product straight into code and the reasoning stops existing the moment the files land. GitHub keeps every commit, but not the fact that a field counts as personal data or that a refund needs a second signature; the next engineer rediscovers both from a diff. The Blueprint holds those decisions, and the code is generated from them.
An edit arrives as a named change operation
An edit lands as a named change — add a field to Customer, with its type and a data classification — rather than as replacement text. Deterministic checks read that record before generation runs, so a rule about personal data stops the change instead of flagging the output a week later.
The stack changes, the truth stays
Because the Blueprint holds meaning, replacing a frontend framework or moving to a different database changes which generator and target adapter run, not the definition of Customer. Entities, workflows and policies reach the new target intact.
What is included
5 capabilities in Blueprints
Each one is its own surface, and all of them answer to the same Blueprint under one set of policies.
The Blueprint Model
Entities and fields, pages and actions, workflows, permissions, policies and capability references, in one structured record.
Read moreTechnology Neutral
Customers, invoices and approvals on one side. Framework, database and cloud on the other. A Blueprint holds the first.
Read moreVersions & History
Published versions are immutable. Every change opens a new version with a comparison against the one before it.
Read moreTyped Operations
A change is recorded as a structured operation: add a field, with a type and a classification. Never as a rewrite.
Read moreBlueprint Studio
One surface for entities, pages, actions, workflows, permissions, policies, capabilities, versions and history.
Read moreThe rest of the product
Six areas, one system.
Capability Graph
The portfolio as a library: every capability with a key, a version, an owner, a status and the products depending on it.
5 capabilitiesAutonomous Builds
Strategy becomes ordered tasks, pull requests and a release that names its inputs. Nothing merges on an agent's word.
5 capabilitiesAI Workforce
Strategy, architecture, engineering, review and release run as separate roles under policy, not as one assistant in a chat window.
5 capabilitiesStop managing prompts. Start managing software strategy.
Connect your repositories. Let Foundariq understand what you have already built. Then tell it what your portfolio should build next.
Read-only to start · Your code stays in your GitHub · [email protected]