The governed core for AI-built software
Your customers are already extending your product. This is how you get to govern it.
A governed core you ship inside your SaaS, so customers can build what they need with AI on rails you define. Policy, approval, audit, isolation, versioning and rollback, as infrastructure rather than a project.
Built on Punica-Editor, our own runtime. Proven by IVYX Studio, a full product built entirely on it and downloadable today.
The request you cannot answer well
Every enterprise conversation reaches the same sentence: can you build this for us?
Say yes
The feature enters your codebase permanently. You wrote it, you own it, you carry it through every release, and it serves one account.
Say no
They build it anyway. Outside your product, against your API, with an automation or an agent nobody reviewed. You will still be the one explaining it the day data moves somewhere it should not have.
Neither answer is about whether the feature is a good idea. Both are about who ends up holding it.
A third answer
They build it inside your product, on capabilities you declared, under policy you wrote.
The code is theirs. The boundary is yours.
| Criterion | Say yes | Say no | Ship a governed core |
|---|---|---|---|
| Who writes it | You | They do, outside you | They do, inside you |
| Who maintains it | You, permanently | Nobody | They do |
| Who sets the limits | You, in code review | No one | You, in policy |
| Your next release | You test it | You hear about it from support | A break-impact report before you ship |
| Where the data goes | You control it | You hope | Declared, gated, recorded |
| What it does to the deal | Won, at a permanent cost | At risk | Won, and priced |
The mechanism
A governed core, not a free-for-all
The moat is not another AI builder. It is the layer that lets AI-generated features integrate with your product safely. Everything an extension, an AI plan or a customer-built feature does passes through one gate.
Policy
Every capability declares the risk it carries. A rule written in advance decides each call, matched on its arguments, before it runs.
Approval
Anything declared high-risk stops and waits for a person. The grant is bound to those arguments, not to the capability.
Audit
Every call is recorded with the rule that decided it, refusals included, under one run identity.
Isolation
A customer-built extension reaches only what its manifest declares. Nothing it did not ask for is in scope.
Versioning
Extensions version independently of your core, against a declared capability contract rather than your internals.
Rollback
A capability can be withdrawn cleanly, because everything that depended on it declared that it did.
How it works
One loop, at the platform level.
Ship a governed core
Give your product a substrate: data model, APIs, workflow, and the capability gateway that governs everything on top.
Customers build with AI
Your customers describe what they need. AI scaffolds a real, runnable capability on the substrate, not a throwaway snippet.
Governance makes it safe
The new capability passes policy, approval and audit before it runs. It cannot break the core, the data, or compliance.
It ships, versioned and reversible
The feature is yours to keep, version, share, or roll back. Your product grows without a roadmap bottleneck.
Proof
We built IVYX Studio on it
IVYX Studio is not a demonstration of this core. It is a full local AI workspace built entirely on it: around 100 extensions exposing more than 500 typed capabilities, a policy engine that decides every one of them, and a signed evidence package for every run.
We did not write a framework and a landing page. We wrote the core, then built the hardest product we could on top of it, and shipped it. Everything the core claims is load-bearing in a product you can download today.
Built on Punica-Editor
The governed core is not a diagram. It is Punica-Editor, the runtime IVYX Studio is built on and the same one you would build on. It is our own technology and it is not open source. You cannot read it, and you do not need to: you can download the product we built with it and run it for a week.
Capability gateway
The gate every capability passes through. Declares risk, enforces what is allowed to run.
Workflow engine
Composes capabilities into steps that can pause for approval and resume.
Kernel services
The host injects its own providers, so the runtime stays decoupled from your product.
Extension system
Where AI-built and customer-built features load, sandboxed to what they were granted.
Alongside it, four smaller libraries are public and MIT licensed: Punica-Request, Punica-Form, Punica-Common and Punica-Components.
What it costs you
Three of them, and none of them go away by not mentioning them.
A contract you can no longer break casually.
Once customers build against your declared capabilities, those declarations are a promise. We give you the tooling to see exactly what a change breaks before you ship it. We cannot make the promise go away, and any vendor who tells you otherwise has not run a platform.
A support boundary you have to decide.
Customer-built extensions are supported by whoever built them. That line needs to be in your terms before the first one ships, not after the first incident.
A pricing decision, not a side effect.
Extensibility does not have to cannibalise your enterprise tier. In every platform that got this right it became one. That is a choice you make deliberately, and it is the first thing to work out.
Not for you if
We would rather you knew now than after the pilot.
Your customers do not ask for customisation.
If that request never arrives, this solves nothing and you should not buy it.
You have only a handful of accounts.
Extensibility is consumed by the top of a customer list. Below a certain size it is overhead.
You would rather build it.
It is a policy engine, a capability registry, an approval path and a signed audit trail. For a small team that is close to a year. We would rather you knew the number than discovered it.
Software is changing shape
Classic SaaS ships a fixed set of features and your customers wait for the roadmap. The next model flips it: you provide a governed core of data, models, workflow and security, and your customers build the long tail themselves with AI. The advantage is no longer how many features you ship. It is having the safest place for others to build on you.
Why now
Vibe-coding and AI-assisted development have reached the end user. For the first time, customers can realistically build the features they need. What is still missing is the layer that lets them do it without breaking the product, the data, or compliance. AI is here today and gets better tomorrow. What lasts is the platform underneath.
Bring us the last customisation request you turned down, and we will show you what it looks like as a governed extension.
Or read how IVYX Studio uses the core, end to end: ivyx.io/how-it-works.