Skip to content
Foundariq

By Cloud Granite Ltd

How it works

From a sentence of strategy to a released change.

Seven stages. Every one of them is inspectable, every automated action is attributable, and nothing reaches a default branch without passing through the gates below.

Start building See the platform
  1. 01Connect the portfolioRead-only GitHub access. Nothing is proposed until the scan is finished.
  2. 02Understand what existsApplications, APIs, entities and shared patterns, mapped into a capability graph.
  3. 03State the strategyPlain language in. Requirements, gaps and a reuse ratio out.
  4. 04Compose the BlueprintExisting capabilities first, new ones only where nothing fits.
  5. 05Validate and check policyDeterministic validation, then the policy engine, then a human where required.
  6. 06Build autonomouslyTyped change sets, branches, pull requests, tests, independent review.
  7. 07Release under gatesEight gates, full provenance, and a rollback that is always available.

Stage 01

Connect the portfolio.

You install the GitHub app against the organisations you choose. Access starts read-only, and it stays read-only until you say otherwise.

Nothing is proposed during this stage. The platform is reading, and reading is all it can do: there is no write scope to misuse, no branch to create and no pull request to open. Revoking the installation ends everything immediately.

Connecting a portfolio

  • Discovering repositories
  • Mapping applications
  • Finding APIs
  • Identifying entities
  • Detecting capabilities
  • Finding shared patterns
  • Building the portfolio graph

Read-only to begin with. Nothing is proposed until the portfolio is understood, and nothing is changed until you approve it.

Demo data

What the first scan found

Repositories
21
Products detected
8
Capabilities identified
104
Shared capability candidates
16
Likely duplicate systems
9
Architecture opportunities
7

Stage 02

Understand what already exists.

The scan produces a portfolio graph: applications, APIs, entities, shared patterns, and the capabilities hiding inside them.

This is the step every code assistant skips, and the reason they keep rebuilding what you own. A portfolio that knows itself can reuse itself.

Stage 03

State the strategy in plain language.

You describe the outcome. The system returns the requirements it inferred, what already covers them, and what genuinely has to be new.

The analysis is the first thing you review, and the last cheap moment to disagree. Every requirement is editable before a single line is planned.

Demo data

Strategy

Build an AI-first web analytics platform. Reuse our existing identity, organisation, billing and event infrastructure. Connect customer data and actual revenue.

Foundariq analysisStrategy understood
Existing capabilities
14
Capabilities extended
3
New capabilities
4
Blueprint
Generated
Composition
Validated
Policy checks
Passed
Human decisions
1

Architecture reuse

76%

A demonstration analysis. The strategy asks for an AI-first web analytics platform reusing existing identity, organisation, billing and event infrastructure. Foundariq reports 14 existing capabilities, 3 capabilities extended, 4 new capabilities, a generated Blueprint, validated composition, passed policy checks, one human decision, and 76 per cent architecture reuse.

Demo data

Composition

“A customer survey platform connected to CRM contacts and analytics.”

Existing
12
Requires extension
2
New
3

Reuse

  • Identity
  • Users
  • Teams
  • CRM contacts
  • Email delivery
  • Analytics
  • Audit

Extend

  • Consent
  • Event tracking

Create

  • Survey management
  • Response collection
  • Survey analysis

Stage 04

Compose the Blueprint.

A Blueprint is the versioned description of what a product is: its capabilities, its contracts, its data, its rules. Not its framework.

Composition prefers what exists. A capability is only created when nothing in the graph fits, and when one is created it joins the graph for every future product.

Stage 05

Validate deterministically, then check policy.

Two different kinds of check, in a fixed order. Neither is a model deciding whether it approves of its own work.

Demo data

This strategy requires

Already available · 6

  • Authentication
  • Organisation management
  • Subscription billing
  • CRM contacts
  • Email delivery
  • Analytics dashboards

To be created · 2

  • Survey management
  • Survey responses

Build two capabilities instead of eight.

How a change gets applied

  1. Agent

    AI proposal

    An agent proposes a change in structured form.

  2. System

    Typed operation

    The proposal becomes a named operation, not a free rewrite.

  3. System

    Schema validation

    Structurally invalid changes stop here, before any model is asked.

  4. System

    Policy validation

    Actual rules are evaluated. No model is asked whether this is allowed.

  5. System

    Risk classification

    The change is graded, and the grade decides what happens next.

  6. Human

    Approval

    Automatic for low risk, a named human for high risk, refused where a rule forbids it.

  7. System

    Apply

    Only now does anything change, and the before state is kept.

AI never receives permission simply because its answer sounds convincing.

Demo data

Capability decision

Three products implement document classification independently

Create a shared capability: document classification, version 1.

The three implementations agree on the important behaviour and differ in naming. Promotion replaces roughly 4,300 lines with one capability and two adapters, and two further products become candidates.

Products affected
3
Impact
Medium
Recommendation
Promote
ApproveKeep product-specificRequest alternative

Deterministic validation answers whether the change is correct. The policy engine answers whether it is allowed. A change that passes the first and fails the second does not ship, and the record says which rule stopped it.

Stage 06

Build autonomously, in your repositories.

Work is expressed as typed change sets, applied on branches, and offered as pull requests your team reads like any other.

Demo data

Change set 342

Proposed by Blueprint ArchitectAgent

  • Add entity: Survey
  • Add field: Survey title
  • Add capability: survey management, version 1
  • Add page: Survey list
  • Add workflow: Survey publishing
Status
Validated
Policy
Passed
Critic
Approved
Demo data

Build

  • Blueprint validation Passed
  • Policy validation Passed
  • Dependency resolution Passed
  • Target resolution Passed
  • Generation Passed
  • Unit tests Passed
  • Integration tests Passed
  • Artifact verification Passed
  • GitHub pull request Passed

All 9 build stages passed: Blueprint validation, Policy validation, Dependency resolution, Target resolution, Generation, Unit tests, Integration tests, Artifact verification, GitHub pull request.

Stage 07

Release under gates.

Eight gates, each with a state you can read. A release is certified when all of them pass, and never because a build finished.

Provenance is captured as the change moves, not reconstructed afterwards. That is what makes the audit trail answerable months later, when the question is why a specific line exists.

Demo data

Release

  • Blueprintv18
  • BuildVerified
  • PolicyPassed
  • Code reviewPassed
  • SecurityPassed
  • QAPassed
  • Artifact provenanceComplete
  • RollbackAvailable

RiskMedium

Demo data

Audit trail

  1. 16:31AgentBlueprint Architect — Proposed change set 342
  2. 16:32SystemSchema validator — Passed
  3. 16:32SystemPolicy engine — Passed
  4. 16:33AgentCritic — Requested one change
  5. 16:35AgentBlueprint Architect — Submitted a revision
  6. 16:36AgentCritic — Approved
  7. 16:37HumanA named human — Approval granted
  8. 16:38SystemSystem — Blueprint v18 published

Append-only. The sequence can be reconstructed, which is what makes an automated change defensible after the fact.

End to end

Sixteen steps, one chain.

Every stage above expands into the steps below. Nothing in this chain is optional, and nothing in it is hidden.

Strategy to release

  1. 01Strategy
  2. 02Product interpretation
  3. 03Capability discovery
  4. 04Blueprint composition
  5. 05Blueprint architecture
  6. 06Critic review
  7. 07Deterministic validation
  8. 08Policy checks
  9. 09Human approval where required
  10. 10Engineering plan
  11. 11AI implementation
  12. 12GitHub pull requests
  13. 13Independent code review
  14. 14QA
  15. 15Build certification
  16. 16Release

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]