What you already have
Every capability names its owner, its version and the products that break when it changes.
Most portfolios keep their software as repositories. A repository tells you where the code lives, not what it means, who owns it, which version is published, or which products break when it changes. The Capability Graph holds the capability composition layer, third of the six: every capability carries a key that outlives its implementation, a version, an owner, a status and the products depending on it. Domains keep it readable as it grows — identity, billing, workflow, consent, analytics. Blueprint composition references those names, so what a product depends on is recorded data rather than something a maintainer remembers.
A repository list is not an inventory
A folder of repositories records location, not meaning. Two teams can build consent handling twice without either one finding out, because a list of repositories cannot answer whether the thing already exists. Code search returns filenames, and a capability is not a filename.
The graph is read before anything is built
Composition queries the graph while the Blueprint is still being assembled, before a generator runs at all. A capability that already satisfies the requirement is referenced; a new one is created only when nothing in the portfolio answers.
The second product costs less than the first
Reuse arrives as a dependency on a published capability instead of a fourth copy to maintain. Each release spends its effort on what is actually new, so the portfolio gets cheaper to extend as it grows rather than heavier.
What is included
5 capabilities in Capability Graph
Each one is its own surface, and all of them answer to the same Blueprint under one set of policies.
Capability Registry
One key per capability, held steady while the code behind it is regenerated, plus version, owner, status, dependencies and consumers.
Read moreConsumers & Impact
Which products depend on which version, direct and indirect, read while a change is still a proposal.
Read moreShared and Product-Specific
Promotion from one product to shared is an explicit step, with the cost and the benefit shown before it happens.
Read moreReuse Opportunities
Analysis that finds two products solving the same problem separately, and proposes the shared capability that replaces both.
Read moreDeprecation & Migration
A published capability cannot simply vanish. Removal without a migration path is blocked by the policy engine.
Read moreThe rest of the product
Six areas, one system.
Blueprints
The Blueprint records what your software means before any file is generated, and a published version of it is what every release points back to.
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]