Glossary

The vocabulary, defined precisely.

Including where each term is usually stretched, because most of the confusion in this category is definitional rather than technical.

Blueprint: The structured record of what a product means: entities, workflows, capabilities, policies, approvals and the limits on what agents may change. It holds no framework, database or cloud choice, because generators and target adapters decide those, which is how business truth outlives a technology change. It is not a design document that sits beside the work — nothing generates until it exists, and every release points back to a version of it.
Capability: A named, versioned unit of behaviour a product uses, such as consent capture, invoicing or audit logging. A capability is defined by what it does and what it guarantees, not by the library that happens to implement it. The word is loose everywhere else; here something only counts as a capability once it has a key, a version and an owner.
Capability key: The stable identifier a capability keeps for its whole life, across renames, rewrites and new implementations. Keys are how two products can be shown to use the same thing rather than two things that merely look alike. A key is not a package name: replacing the implementation keeps the key, while forking the meaning requires a new one.
Composition: Assembling a product from existing capabilities and declaring how they connect, instead of writing each one again. Because composition is declared in the Blueprint, the wiring can be inspected and changed without reading the code. It does not make integration free — capabilities still have contracts, and a mismatch surfaces as a validation error rather than a runtime surprise.
Reuse ratio: The share of a product's capabilities that came from the portfolio rather than being created for it. Tracked across several products, it shows whether the portfolio is compounding or just growing. Read it with care: a high ratio can also mean capabilities were stretched to fit, so check it against how often a shared capability had to change for one consumer.
Typed operation: A change an agent is permitted to request, defined by a schema — add a policy clause, raise a field's classification, require a second approver. The set is finite, and each operation carries its own validation rules and risk class, so a request outside the set cannot be expressed at all. In normal copy these appear in plain language, as "Change field", not as their internal identifiers.
Change set: A proposed group of typed operations against a Blueprint, reviewed and approved as one unit. It carries the diff in business terms, the products and capabilities affected, the assigned risk class and the approvals required. A change set is not a commit: commits come later, after validation, generation and independent review.
Policy profile: The rules a portfolio, product or environment is evaluated against — who approves what, which agents may touch which areas, which data may leave, what must be logged. Profiles are evaluated deterministically before any model judgement, so an action proceeds because a rule says so, never because an answer sounded convincing. A profile is only as good as what you put in it: the engine enforces rules, it does not invent them.
Risk classification: The category assigned to a change based on what it can break — a new optional field is not the same as changing an authentication rule or dropping stored data. Classification is what routes a change to automated checks, to an independent review, or to a named human approver. The rules are visible, so you can read why a change was classified as it was and change the rule if you disagree.
Data classification: Labels on the data described in a Blueprint: personal, financial, health, secret, public. The labels drive policy — which agents see which fields, which model routes are permitted, what reaches logs, how long anything is kept. Labelling is a judgement your team makes; Foundariq enforces the consequences rather than guessing what is sensitive on your behalf.
Critic: An independent agent that reviews what a proposing agent produced, with its own context and its own instructions. A critic can object, and it never reviews its own output, because the builder and the reviewer are always separate parties. A critic's verdict is an input, not a permission: the policy engine still evaluates the change, and a human still approves where the profile requires it.
Separation of duties: The rule that whoever proposes a change is never whoever clears it. Architect proposes, critic reviews, the policy engine evaluates, a human approves where required; on the code side, the agent that wrote the change opens a pull request and a different reviewer reviews it. It is enforced by the control plane rather than trusted to convention, which means it applies just as strictly when the proposer is a person.
Provenance: The record of what produced an artifact: Blueprint version, generator version, capability versions, policy profile, dependencies and lock files. It answers why a piece of code exists and what decided it, which source control on its own cannot. Provenance records inputs rather than intent — the argument behind a decision lives in the change set and its approvals.
Build hash: A fingerprint over everything that went into a build. Two builds sharing a hash came from the same inputs; a different hash means something changed, and the provenance record names it. The hash proves sameness of inputs, not correctness — a reproducible build of a wrong Blueprint is reproducibly wrong.
Generator: The component that turns a validated Blueprint into code for a chosen stack. Generators are versioned, and the version is stored with the release, so the same Blueprint and the same generator produce the same output. A generator makes no product decisions: everything it emits traces to something the Blueprint already stated.
Target adapter: The piece that knows one specific destination — a language, a framework, a runtime, a cloud. Adapters are where technology choices live, which is exactly what keeps them out of the Blueprint; changing the adapter re-expresses the same meaning somewhere else. Swapping one is still engineering work, since adapters carry defaults and constraints, and a target that cannot express a capability reports that rather than improvising.
Capability pack: A set of capabilities published together with their contracts and versions, ready for another product to adopt. Packs are how a shared capability travels between teams without being copied and quietly diverging. Adopting a pack creates a real dependency: the consumer tracks versions and deprecations instead of owning a private fork.
Deprecation: A marked state on a capability or published version: still available, no longer the recommended choice, with an end in view. Marking it lists every consumer that depends on it, so the cost of retirement is known before retirement is scheduled. Deprecation is not deletion — nothing disappears because it was deprecated, and consumers move along a migration path.
Migration path: The defined route from one published version to the next: what changes for consumers, and which steps run automatically. Paths are attached to the version that introduced the break, so the instructions travel with the change instead of living in one engineer's memory. A path reduces the work rather than removing it; each consumer still has to run, review and release it.
Published version: A version of a Blueprint or capability that has been validated and released for others to depend on. Published versions are immutable: a correction becomes a new version, never an edit of the old one. Work in progress is never published, so nothing can take a dependency on something that is still moving.
Audit trail: The sequential record of what was proposed, what validation found, who reviewed, who approved and what was released. Entries are linked to the ones before them, so a missing or altered entry is detectable, and the interface reports this plainly as audit integrity verified. The trail records decisions, not everything a model ever said; drafts and prompts are held separately.
Model routing: The rules deciding which model handles which class of task — proposing, reviewing, summarising, generating. Routes can be pinned by data classification, sending sensitive work to a named provider or a private deployment, and can point at your own keys and endpoints. Routing changes cost and quality; it never changes what is allowed, because validation and policy run identically whatever answered.
Engineering plan: The ordered work derived from an approved change set: which capabilities are reused, which are created, what each agent does, in what sequence. It exists before code so it can be argued with while arguing is cheap. It is a plan for one change, not a roadmap — if the Blueprint moves, the plan is re-derived rather than patched.
Build certification: The statement that a build met the checks required for its risk class: validation, tests, independent review, policy evaluation, and a complete provenance record. It is assembled from results, not asserted by an agent that reviewed itself. Certification covers what was checked; it makes no claim about correctness in areas nobody tested.
Release gate: The point where a build either becomes a release or stops. The gate reads deterministic results — your CI, Foundariq's validation, required approvals, certification — and names the condition that failed. A gate holds no opinion and cannot be talked past: if a rule needs to change, the policy profile changes, and that change is recorded too.
Portfolio graph: The map of products, capabilities, versions and dependencies across everything connected. It answers which products share a capability, what breaks if a version is retired, and where two teams built the same thing twice. The graph shows what is declared and connected — a repository nobody connected is simply not in it.

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.

Start building See how it works

Read-only to start · Your code stays in your GitHub · [email protected]