Platform layer
Schema first, policy second, risk third — no model in the path.
A proposal arrives as a named operation and meets three passes in a fixed order. Schema validation resolves every reference and every type in the operation, and a structurally invalid change stops there, with the failed check named and no model consulted. Policy evaluation then runs the profiles in force — portfolio, then product, then environment — and the strictest outcome wins, so a product-level allowance cannot loosen a portfolio-level refusal. Risk grading comes last and reads only what the operation touches: the shape of an entity, a permission, a published capability, a field carrying a classification. Each pass records what it checked and what it returned, and those three results together are the route the change takes.
Validation runs before judgement
Schema checks and policy evaluation run on the proposal itself, not on generated code and not on a model's explanation of the proposal. Removing a published capability with no migration path fails a rule before a reviewer reads a word of it.
Rules are evaluated, not interpreted
A policy is a rule the engine executes: this field is restricted, this class of change needs a named approver, this action is refused. There is no prompt in that path and no model output to weigh, so the same proposal produces the same verdict every time. AI proposes. Policy decides.
Risk decides the route
Every validated change is graded, and the grade routes it. Interface copy applies automatically, because nothing is gained by making someone approve a label. A change that can lose data waits for a named person, and a small set of actions — deleting production data among them — has no setting that lets an agent perform it.
Refusals state their reason
A blocked change comes back with the rule that blocked it, written the way the policy is written, and the proposal is kept rather than discarded. An engineering leader can see why the engine said no without reading a log or reconstructing a model's reasoning.
What this layer does
- Validates every proposed change against the schema before any model judgement is involved.
- Evaluates your policies deterministically: same proposal, same verdict, every time.
- Grades each change by risk and routes it to automatic, named approval, or refusal.
- Keeps a class of actions unavailable to agents entirely, with no configuration that opens them.
- Records what was checked, what passed, what was blocked and who approved.
What it does not do
The policy engine does not write your policy and does not infer intent — it evaluates the rules you configured, and a rule nobody wrote is a rule nobody enforces. It also makes no judgement about whether code is good; that is what independent review and the test suite are for.
The platform
Six layers between strategy and software.
Blueprint Engine
Blueprints hold what a product means: structured, versioned, validated, and readable long after the stack changes.
How it worksComposition Engine
Before anything is created, Foundariq checks what the portfolio already has. The reuse ratio is what it reports back.
How it worksPolicy Engine
Checks run before any model is consulted. The control plane evaluates policy; it never asks an AI whether an action is allowed.
How it worksGitHub
Foundariq opens pull requests in your own repositories. Nothing is mirrored, hidden or locked away from your team.
How it worksMulti-Model AI
Every job resolves to a provider, a model and a pinned version before the run starts, and a run the rules cannot staff does not start.
How it worksAPI
Everything the interface does, the API does: Blueprints, capabilities, change sets, builds, decisions and audit records.
How it worksStop 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]