Skip to content
← Blueprints

Everything the software has to mean, in one record.

A Blueprint holds the nouns of your business and what may be done with them. Entities and their fields describe what exists; pages and actions describe where people work and what they may do there; workflows describe what happens in sequence and where someone has to sign off. Permissions state who may act, policies state what must hold, and capability references state which parts the portfolio already provides. Read end to end, it answers what the product does without naming a single library.

A field carries a type and a classification

A field is recorded with its type and what it actually is: an email address, a monetary amount, personal data. That classification is what a policy can act on later, which is why it belongs in the Blueprint rather than in a migration script.

Workflows name the step that needs a human

A workflow records its steps, the transitions between them, and the points where an approval must land before the next step runs. Because the requirement sits in the Blueprint, the generated product and the control plane work from the same statement of it, instead of two versions that drift.

Shared capabilities enter by reference

Where a Blueprint needs something the portfolio already provides, such as consent capture, billing or notification, it points at that capability instead of restating its internals. A new capability is created only when nothing existing satisfies the requirement, so each product leaves the next one less to build.

In this capability

  • Entities and fields
  • Pages and actions
  • Workflows and approvals
  • Permissions and policies

Stop 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]