Talk to us

For the organisation that has to answer for it

Use AI to move faster without losing control of the system.

Cisely directs agents to an application model that people can review. The model makes system behaviour, permissions and business intent explicit; deterministic generation turns the approved definition into coordinated implementation assets.

Talk to us How you would check it

Would you rather we built it with you? See Outcome Engineering

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.

Separate judgement from generation

Agents help author the model. Deterministic tools generate the system.

People review the application definition; agents help create and maintain it; validation and code generation turn the approved model into coordinated implementation assets.

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

Model controls with the application, not after it.

Declare isolation, authorisation, validation and audit requirements alongside system behaviour. Cisely validates the definitions together and derives their implementation.

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

Move from generated code to a managed application.

Cisely provisions the application environment defined by the deployment contract, including isolated data, messaging, cache, storage, compute, gateway and public hosting resources.

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

Keep platform tenancy and application tenancy distinct.

Your organisation must be isolated from other Cisely customers, while the application you build may also need to isolate its own customers. Cisely models these as separate layers.

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 source model and regenerate dependent assets together.

Keeping schemas, APIs, clients, tests and documentation coordinated is a major maintenance cost. Cisely derives them from the same application definition.

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.

Approval requirements attach to the operation itself, so they apply whether the caller is a person, the built-in agent or a connected external agent.

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

Turn declared controls into explicit assurance obligations.

Because controls are modelled, Cisely can derive falsifiable behavioural obligations and report which ones have supporting verification evidence and which remain outstanding.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

Or have it delivered

The same platform, run for you as a software factory.

Outcome Engineering is a partnership: we agree with you what a successful outcome looks like, then build the entire product alongside your team on Cisely — through to a running system, with day-one operations included.

How Outcome Engineering works

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