For the organisation that has to answer for it
Build fast and build right. Those stopped being a trade.
The objection to agentic development in a large organisation was never that the code is bad. It is that six months later nobody can say what the system does, who may call it, or which promise any of it was making. That is a question about where the agent is pointed — and here it is pointed at a model the business can read, from which the system is derived.
- You
- Intent and judgement
- What the business means, what it promises, and what the system must refuse. Nothing below is decided without this.
- Paroksh
- Drafting
- Turns that into a model, and stops to ask when the answer is a judgement rather than a fact.
- The compiler
- Derivation
- Backend, schema, migrations, API, contracts and typed clients — from that model, identically, every time.
Fast and right, at the same time
The agent authors the model. The compiler writes the system.
Two different kinds of work, and only one of them is probabilistic. That single separation is what lets an enterprise take the speed of agentic development without taking on a system nobody can account for.
- Generation is deterministic
- The same model compiles to the same backend, schema, migrations, contracts and clients, every time. A rebuild is not another roll of the dice, and two engineers asking for the same thing do not get two different systems.
- Review moves up a level
- You review a declaration a person can hold in their head, not a diff of thousands of generated lines. What was approved is what compiles — so review is a control again rather than a ceremony nobody has time for.
- A wrong suggestion has a bounded blast radius
- An agent writing code can put anything anywhere. An agent editing a model can only say what the language can express, and the compiler refuses the rest — before it is code, let alone running.
- Speed is not borrowed against the future
- The usual trade is velocity now for a codebase nobody can reason about later. Here the artifact that was quick to produce is the same one you maintain, and it is the one written in your business’s own vocabulary.
- And it is why the rest of this page can be counted
- Because the controls are declarations and generation is deterministic, the toolchain can enumerate what the running system promises. An assertion becomes an inventory — which is the last section here.
By construction
The controls are not a hardening phase. They are what the model compiles into.
In an ordinary build, isolation, authorization, validation and audit are retrofitted once the demo works — which is why they are the two quarters nobody budgeted. Here they are declarations, and the substrate derives the enforcement.
- Tenant isolation
- An aggregate declares the axes it is isolated on. The database enforces it with row-level security generated from that declaration — not a filter a query can forget to apply.
- Authorization
- A command carries policy leaves and guards. Each one is a statement about who may act and when a write is refused, and the toolchain can enumerate every one of them.
- Typed failure
- Errors are declared with a code, a severity and an HTTP status, and a route declares the statuses it can legitimately answer. A client knows what to handle before it is written.
- Input validation
- A spec binds to the field and to the command input that carries the value into it, so a constraint cannot hold on the way out and not on the way in.
- Audit
- Timestamps, immutable fields and append-only revisions are part of the declaration. What changed and when is not a feature somebody remembered to add.
What you do not have to build
A platform-engineering programme, not required.
Generated code is not a running system. Everything between the two is provisioned per application and operated for you — the part that usually costs more than the application it carries.
- Its own database
- A physical database on a managed cluster, with the extensions the model declares, and separate owning and request-path roles.
- Its own namespaces
- An event-bus topic and consumer-group namespace, a cache key namespace and object-storage buckets — each scoped by credential to that application alone.
- Its own edge
- A dedicated API gateway carrying the application’s generated configuration, behind the shared platform edge. Certificates are issued and renewed for every host.
- Compute that follows the work
- Request-driven services that idle down to nothing, long-running processes that follow event backlog, and one-shot jobs for schema migration.
- Secrets that survive a release
- Session, signing and encryption keys are generated once per application and preserved across redeploys.
Two questions, two answers
Tenancy has two levels here, and they nest.
“How are we separated from your other customers?” and “how are our customers separated from each other inside our application?” are different questions. Conflating them is how a security review stalls.
- Between applications
- The platform separates them: a separate physical database, a credential-scoped event-bus namespace, a separate cache namespace, separate buckets and a separate compute namespace.
- Inside an application
- Your own end customers are separated by the row-level security the framework generates from the isolation axes your model declares.
- Names you cannot guess
- Every physical name — database, roles, buckets, event-bus prefix, public hosts — derives from a durable identifier the platform allocates and holds unique. A project name is a readable suffix and confers no naming power. Deriving infrastructure names from user-supplied text is a collision risk and an injection surface; this is a security property, not tidiness.
- Addresses that hold still
- API and web hosts derive from that same identifier, so they survive a redeploy. A published link or a configured callback keeps working through the next release.
The years after the first release
Change the model, and what was derived from it follows.
Most of what an enterprise system costs is spent after it ships, keeping a codebase and the reasons behind it from drifting apart. That cost is structural, and this is where it is attacked.
- Migrations are derived, not written
- Schema change comes from comparing the model with the database, rather than from someone hand-writing the diff and hoping it matches.
- Contracts stay compatible
- API contracts are generated alongside the backend, so clients already deployed keep working across a release.
- A rename happens once
- The name lives in the model. Everything derived from it — schema, API, typed clients — moves together instead of being chased through a codebase.
- Hand-written code is confined and countable
- Imperative code lives only in declared seams. In the platform’s own reference application those seams are about one percent of what the model generates — and you can count them, which is the point.
- One build, promoted
- The same build artifact moves between environments; what differs is configuration rather than architecture. Adding an environment is a configuration change, not a project.
Governing what the agent does
The same approval rules apply to an agent’s action as to a person’s.
Most AI governance stops at the human interface and leaves the agent a second, quieter path to the same operations. Here the rule attaches to the operation, so there is only one path.
- The requirement belongs to the operation
- An operation that archives a record carries its own risk level and approval requirement. Any assistant granted that operation inherits it — including one granted it later.
- Risk is graded
- An additive, high-frequency action such as recording a measurement can proceed unattended. A consequential state change requires a confirmation. A destructive one can require two people.
- A suspended action is a durable record
- What was attempted, the state needed to resume it, a key that prevents an approved action running twice, and who decided. These records are never deleted.
- Unattended does not mean unsupervised
- An agent running with nobody watching parks its action for an operator rather than failing silently or proceeding on its own.
- The ask is blocking, and cannot be waved away
- When Paroksh needs a decision, the request is modal and undismissable, and the agent is genuinely blocked on the reply. Every write is performed as the signed-in person, through the same permission-checked operations they would use themselves.
How you would know
Every vendor asserts this. The model can be made to enumerate it.
Because the controls are declarations rather than code, the compiler can count them. It derives one obligation per falsifiable statement the model makes about runtime behaviour, and reports how many of them have evidence behind them.
An obligation per statement
Every guard, policy leaf, spec, typed error, route error-list, unique index and isolation axis becomes a named obligation — “this caller is refused”, “this transition is refused”, “this input is rejected”. The model is the denominator, so the number cannot be inflated by writing more tests of the same thing.
Six dimensions, and the weakest one wins
Specification, verification, process coverage, isolation and authorization, deployment readiness, and claim honesty. The overall level is the minimum the dimensions allow, not an average — a strong dimension cannot cover for a weak one.
One binding constraint
The report names the single thing standing between the model and its next level, rather than handing over a list to triage.
Waivers are accountable
An obligation covered by a control outside the model can be waived — with a reason, a named owner and an expiry date. An expired waiver stops excusing anything.
It runs as a gate
A floor the build must clear, and a comparison against the previous report that fails when the model starts saying less. Removing a constraint to improve the number adds a finding in its place.
It states its own blind spots
The report distinguishes what static analysis showed from what ran in memory from what was proven against a real deployed stack — and it refuses to call tenant isolation proven until the last of those exists. That refusal is the reason to trust the rest of it.
We do not publish the scores. They measure how far a verification programme has got, not how good a product is, and a number offered without that context is worth nothing to you. Ask us in a review and you will be walked through the real report, including the parts of it that are still empty.
Procurement and exit
Your repository stays yours.
The questions a vendor security review actually asks are about custody and exposure, and they are cheaper to answer when the answers are structural.
- No custody of your source
- Initialising a project adds no git remote and stores no git credential. `origin` is entirely yours, with your own branching strategy. Builds upload the working tree rather than requiring us to hold pull access.
- Generated code is delivered to you
- Code generation runs on the platform and the result is delivered to a branch of your own repository. You never install the generation toolchain, and it never enters your build pipeline.
- Authoring works offline
- Local validation needs no account and no network, so the feedback loop that matters most does not depend on us being reachable.
- No lock-in to one model vendor
- The agent is not the model underneath it. Point it at Claude, at Codex, or at the provider Cisely runs — the approval gates, the audit trail and the division of labour hold whichever one answers, so a change of provider is not a change of control.
- What you end up with is ordinary
- A backend, a database, an API, typed clients and a web application, on standards-based artifacts. There is no runtime of ours to keep in your stack.
The conversation worth having is about your model, not our platform.
Bring one initiative you are about to build. We will model it with you — the intent, the systems, the isolation, what refuses what — and you will see the whole chain before you commit an engineering team to it.
Talk to us