One product is priced per seat. A portfolio is not.

Foundariq is an Autonomous Software Portfolio OS. You decide what should exist; Foundariq handles how it gets built. Strategy goes in and becomes a Blueprint: the structured record of what your software means, which capabilities already exist, which must be created, and which policies apply. Generation, validation, review and release all run against that Blueprint, and every release traces back to a version of it. Strategy in. Verified software out.

A coding agent starts with code — a file, a prompt, a diff. Foundariq starts with business truth: what the product must mean, which capability already does this, which policy applies, who has to approve. Code generation happens here too, as the fifth of six layers, and the pull request it opens still faces an independent reviewer and the policy engine. Keep the agent in your editor; Foundariq governs the portfolio it types into.

No. Repositories, branches, commits, pull requests, reviews, CI and releases stay exactly where they are, in your GitHub, under your account. Foundariq adds the layer above them: the Blueprint, the capability inventory, the policy profile, the provenance behind each change.

A Blueprint is the structured description of what a product does: entities, workflows, capabilities used or created, policies, approvals, and the limits on what agents may change. It holds meaning, not implementation — no framework, no database, no cloud choice, because generators and target adapters decide those. That separation is what lets business truth survive a technology change. Blueprints are versioned, and a published version is never edited, only superseded.

Without it, generation guesses. The Blueprint is what makes the reuse check possible: you cannot ask whether a capability already exists if nothing records what exists. It is also what policy attaches to, because risk class, data classification and approvers are properties of the meaning rather than of a diff. And it is what makes a release traceable, since the release points back to the Blueprint version that produced it.

Foundariq reads your repositories and drafts a first Blueprint and capability inventory from what is already there — entities, workflows, and the things you have quietly built twice. You correct that draft; it is a starting point, not a verdict. Nothing is rewritten and no migration is required to begin. Your first change runs the same path as every other one: change set, validation, generation, independent review, pull request.

No. Agents produce change sets and pull requests; they do not deploy. What an agent may touch is set by your policy profile and evaluated deterministically, before any model judgement runs. Your branch protection, your CI and your deployment pipeline still stand between a merged pull request and production, and Foundariq has no path around them.

Agents can only request typed operations — a finite, schema-defined set — so a change outside that set cannot even be expressed. Each operation carries a risk class: dropping a field, changing an authentication rule or touching classified data routes to a named human approver. Deterministic validation runs before any AI judgement, and the control plane evaluates actual policy instead of asking a model whether something is allowed. What stops it is the schema and the policy profile, both of which you can read.

Your policy profile names the approver for each risk class, and the engine routes changes accordingly. Low-risk work clears automated validation and an independent critic review, then arrives as a pull request you merge. Higher-risk work waits for the named human, and nothing proceeds while that approval is outstanding. Every approval is recorded: who, when, which Blueprint version, which change set.

No, and that is enforced rather than encouraged. An architect agent proposes, an independent critic agent reviews with its own context, the policy engine evaluates the change against your rules, and a human approves where the profile requires it. On the code side, the agent that wrote the change opens a pull request and a different reviewer reads it.

A capability is a named, versioned unit of behaviour — consent capture, invoicing, audit logging — with a stable key and an owner. Before anything is created, Foundariq searches the portfolio for a capability that already satisfies the requirement, and a new one is created only when nothing does. Reuse is why the third product costs less than the first, and why a fix lands once instead of five times. Every product should make the next product easier to build.

Yes. Model routing is a rule set you control: which provider handles proposing, reviewing, summarising or generating, using your own keys and endpoints where you want them. Routes can be pinned by data classification, so work touching classified fields goes to a specific provider or a private deployment. Which model answered changes nothing about what is allowed, because validation and policy run the same way regardless.

Yes. Every release records the Blueprint version, generator version, capability versions, policy profile, dependencies and lock files, summarised as a build hash. The same inputs produce the same artifact; when an output differs, one of those inputs changed and the provenance record names it. You can point at a file in your repository and ask which Blueprint version and which generator produced it.

The change becomes a change set: a diff in business terms, such as a field added, a workflow step changed, a policy tightened. Validation runs, affected capabilities and dependent products are listed, a risk class is assigned and approvals are routed. Only then does generation run and pull requests open, one per affected repository. The version you changed from stays immutable, and the new version carries a migration path for anything that depended on it.

Yes. Generated code is ordinary code in your repositories, readable and editable by anyone on the team. Generators write into defined areas and leave the rest alone. Where hand-written work contradicts the Blueprint, Foundariq reports the drift and shows both sides rather than overwriting what you wrote. This is a permanent way to work, not a migration step: the Blueprint governs the shape, people still write the parts worth writing by hand.

The code is already in your GitHub, in your repositories, under your own account — there is nothing to extract, because nothing was ever held anywhere else. Blueprints, capability definitions and policy profiles export as structured files you keep. What you lose is the layer above: the reuse check before something is built, the policy evaluation before it lands, the provenance behind each release. The software keeps running; the organisation around it stops.

Yes. Foundariq opens pull requests, so your checks run exactly as they do for a human contributor. The release gate reads your CI results alongside Foundariq's own validation and the build certification, and a red build stops a release. There is no override button: if a rule has to change, it changes in the policy profile, and that change is recorded too.

Data classification lives on the Blueprint, with fields marked personal, financial, health or secret. Those labels drive policy: which agents see which fields, which model routes are permitted, what is written to logs, how long anything is kept. Building does not require production data, since generation works from the Blueprint and fixtures. Classified fields stay out of model context unless your policy profile explicitly allows it, and that allowance is visible in the audit trail.

Connect GitHub. Foundariq reads your repositories and drafts a Blueprint and capability inventory for what you already run — the CRM product, the billing product — and you correct what it got wrong. Then take one small change, a single field or a workflow step, and run it end to end: change set, validation, engineering plan, generation, critic review, pull request. Day one finishes with a reviewable pull request in your own repository and a provenance record behind it.

No. It contains one, and that generator is deterministic and versioned, which matters — but it is the fifth of six layers, not the product. A generator that does not know which capability already exists, which policy applies or who must approve produces code quickly and portfolio debt faster. The six layers run in order — strategy, blueprint, capability composition, policy and validation, build and AI engineering, verification and release — and generation is one step inside the fifth. The work is the other five around it.