Software Factory · the Precise half of Cisely
Enterprise software, built the same way every time.
Describe the application once, in the language of your business. The Software Factory compiles it into a complete, running application. It tests every promise the application makes, and releases it to our hosting or your own cloud.
From one model
- A backend and its database
- Go and PostgreSQL, with migrations planned from the model.
- A documented, secured API
- With OpenAPI and AsyncAPI descriptions.
- Typed clients
- For the web, for mobile and for the command line.
- Its own AI agents
- Declared in the model, and open to outside assistants through MCP.
- The tests for every promise
- From one plan, in Go, HTTP and TypeScript.
How it works
From a description to a running application.
Describe it once.
Paroksh writes the application in Vishwakarma, the application modeling language, in the vocabulary of your business. You rarely write it by hand.
Check it before it runs.
The checker reads the whole model and catches problems before anything runs. Each of its 745 diagnostics explains itself.
Compile it and see it run.
The factory compiles the model into a complete application. You see it run in the Workshop, next to the model it came from.
Release it where you choose.
A merged change starts a release build. The platform provisions what the application needs, on our hosting or in your own cloud.
Built right by construction
The floor every application starts on.
Most teams add these controls after the first release, if they remember. Here they come from the model, so nobody has to remember them. A team of four gets the same floor as a bank, and the bank also gets the evidence to show a regulator.
- Tenant isolation
- Row-level security and database roles derived from the model, so one customer cannot read another — enforced in the database, not remembered in a query.
- Authorization
- Policies declared against operations. The requirement belongs to the operation itself, so a new caller cannot route around it.
- Validated input
- Field specs and invariants checked wherever a value crosses a trust boundary, rather than at whichever handler someone remembered.
- An audit trail
- Domain events recorded as facts as the system runs, because the record of what happened is derived rather than added later.
- Migrations
- Derived from the model and not hand-written, so the schema and the description of it cannot drift apart.
- An API, contracts and typed clients
- The HTTP surface, its OpenAPI description and the clients that call it, all generated from the same source.
Bring your own identity provider and your own authorization engine. Your policies stay declared in the model.
Assurance
We count promises, not lines.
A coverage report counts lines of code, and running a line proves no behaviour. The Software Factory lists every promise the model makes, and measures verification against that list.
- Promises come from the model
- Each rule, guard, policy, isolation boundary, event and route contract becomes an obligation. Nobody can quietly shrink the list.
- Six dimensions
- Verification is scored in six dimensions. Isolation and authorization each get their own score.
- Levels an auditor can check
- From L0, the model compiles, to L3, green against a real deployed stack. Each level is a set of statements you can audit.
- Assurance cannot slip unnoticed
- Waivers expire and stay visible. The build fails if assurance drops below what it was.
How it works, in full: what assurance is.
The Workshop
Review the model and the running app, not piles of code.
In the Workshop, you see every layer of the application next to the model it came from. Each session ends in a proposed change. Your team reviews it with diffs that understand the model, and a merge starts the release build.
- App
- Domain
- Application
- Systems
- API
- Flows
- Coverage
- Assurance
- Changes
- Source
What you can build
Applications with real rules, workflows and accountability.
The Software Factory is general purpose: any business system can be built on it. The best fit depends on structure more than industry: what data must stay separate, how work moves, which rules apply and what evidence people will ask for. Each type links to the modelling concepts behind it.
Multi-tenant products
Many customers, one system, and nothing of theirs may touch anything of anyone else’s.
The shape most software businesses are. Tenancy here has two levels that nest — how your customers are separated from each other, and how their users are separated inside each one — and both are modelled rather than remembered. The separation is derived into the database, so it holds for a query nobody has written yet.
Workflow and approval systems
Work that moves through states, waits on people, and must not lose its place.
Anything where a request is raised, reviewed, approved, escalated or rejected — and where the interesting failures are the half-finished ones. These are modelled as state machines with their guards declared, so a step that cannot legally happen does not compile rather than failing at two in the morning.
Systems that have to be answerable
Somebody will ask you to prove it, and "we tested it" is not the answer they want.
Where a control has to be demonstrated rather than described — to a regulator, an auditor, a customer’s security review. Obligations are declared against the model and graded, and the report is produced from the substrate rather than assembled by hand the week before the audit.
Internal systems that outgrew the spreadsheet
The thing five people depend on that lives in a sheet, a form and somebody’s inbox.
Operations tooling, back-office systems, the process that runs on glue. These are usually not hard — they are just never worth a team, so they stay fragile. When the description is the system, the thing that was never worth building becomes worth building, and it arrives with the same floor as everything else.
Yours to keep
Your code. Your cloud. Your model.
Take your code at any time, run it in your own cloud, and choose your AI model.
- Your code
- Pull the generated code into your own repository at any time.
- Open infrastructure
- Go, PostgreSQL, standard containers, Kubernetes and React. Nothing only we can run.
- Your cloud
- The same deployment contract runs on our hosting or in your own cloud.
- Your AI model
- Paroksh uses the model you trust, or the subscription you already pay for.
In depth
The engineering case, for the people who will review it.
How the factory generates a system, what it provisions, how it separates tenants, how it governs agents and how you would check all of it.
Separate judgement from generation
Agents help author the model. Deterministic tools generate the system.
Agents help create and maintain the application definition. People review it. Then validation and code generation turn the approved model into the code that implements it.
- 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. Two engineers who ask for the same thing get the same system.
- 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 you approve is what compiles. Review becomes a control again, not a ceremony that nobody has time for.
- A wrong suggestion has a bounded blast radius
- An agent that writes code can put anything anywhere. An agent that edits a model can only say what the language can express. The compiler refuses the rest, before it becomes code and long before it runs.
- Speed does not borrow 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 one you maintain. It uses the vocabulary of your business.
- 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, and the assurance band below shows it.
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 states who may act and when the system refuses a write. The toolchain can list every one of them.
- Typed failure
- Each error declares a code, a severity and an HTTP status. Each route declares the statuses it can answer. A client knows what to handle before anyone writes it.
- Input validation
- A spec binds to the field and to the command input that carries the value into it. So a constraint holds on the way in as well as on the way out.
- 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. The platform issues and renews certificates 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
- The platform generates session, signing and encryption keys once per application, and keeps them across redeploys.
Two questions, two answers
Keep platform tenancy and application tenancy distinct.
Cisely must isolate your organisation from its other customers. 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
- Row-level security separates your own end customers. The framework generates it from the isolation axes that 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. Names built from user-supplied text risk collisions and injection. So 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.
It costs a lot to keep schemas, APIs, clients, tests and documentation in step. Cisely derives them all from the same application definition.
- Migrations are derived, not written
- Cisely plans each schema change by comparing the model with the database. Nobody hand-writes the diff and hopes that it matches.
- Contracts stay compatible
- Cisely generates API contracts with the backend, so clients that are already deployed keep working across a release.
- A rename happens once
- The name lives in the model. Everything derived from it moves together: the schema, the API and the typed clients. Nobody chases the name 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. You can count them, and that is the point.
- One build, promoted
- The same build artifact moves between environments. Only the configuration differs, not the architecture. A new 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 that gets the operation inherits the requirement, including one that gets 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. Cisely never deletes these records.
- Unattended does not mean unsupervised
- When nobody watches an agent, it parks its action for an operator. It does not fail silently or act on its own.
- The ask is blocking, and cannot be waved away
- When Paroksh needs a decision, it shows a request that you cannot dismiss, and it waits for your reply. Paroksh performs every write as the signed-in person, through the operations that person would use.
Procurement and exit
Your repository stays yours.
A vendor security review asks about custody and exposure. Those questions are easier to answer when the answers are part of the structure.
- 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, so we never need 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.
- 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 that Cisely runs. The approval gates, the audit trail and the division of labour hold for each one. 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.
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.
An obligation per statement
Every guard, policy leaf, spec, typed error, route error list, unique index and isolation axis becomes a named obligation. Examples: “this caller is refused”, “this transition is refused”, “this input is rejected”. The model is the denominator, so more tests of the same thing cannot inflate the number.
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 says less. Removing a constraint to improve the number adds a finding in its place.
It states its own blind spots
The report separates three things: what static analysis showed, what ran in memory and what a real deployed stack proved. It refuses to call tenant isolation proven until the last of those exists. That refusal is the reason to trust the rest.
We do not publish the scores. They measure how far a verification programme has got, not how good a product is. Without that context, a number is worth nothing to you. Ask us in a review, and we will walk you through the real report, including its empty parts.
For builders
Technical questions.
Is this a code generator?
It generates a backend, a database schema and its migrations, an API and its contracts, and typed clients. But generation is the last step, not the product. The software comes from the same model as your mission, strategy and customer expectations, so it cannot drift from what it is for.
Do I have to read generated code to stay in control?
No. You direct and judge, and the agent builds. The Workshop shows one model through nine lenses, from the running app to its assurance. The source code is there when you want it, not because you need it.
What happens when I change my mind?
You change the model, and everything that comes from it follows. You make a rename once. Cisely plans the database changes by comparing the model with the database. API contracts stay compatible with the clients that are already deployed.
How much hand-written code ends up in the system?
Hand-written code lives only in declared seams, so you can count it. In the platform’s own reference application, those seams are about one percent of what the model generates. The exact number matters less than the fact that you can know it.
What can the agent change without asking me?
The approval rule belongs to the operation, not to the agent, so a different caller cannot escape it. Risk is graded. A frequent, additive action can run unattended. A consequential change needs a confirmation, and a destructive one can need two people. When Paroksh needs a decision, it stops until you answer.
What happens between sessions?
The agent does not persist, but the work journal does. Decisions, lessons, checkpoints and runbooks attach to the same parts of the model as everything else. A new session starts by reading what the last one concluded.
Where does the application run?
On infrastructure that Cisely provisions for each application. It gets its own database with separate roles, its own event and cache namespaces, its own storage buckets and its own API gateway. Certificates are issued and renewed for every host. Nobody has to assemble or operate any of it.
How are we isolated from your other customers?
There are two answers. Between applications, the platform separates you: a separate database, separate namespaces and buckets, and separate compute. Inside your application, the database separates your own customers with row-level security, generated from what your model declares. The platform allocates every physical name, so no project name can collide with another customer’s resources.
What uptime or scale do you commit to?
Cisely publishes no uptime, scale, recovery or data-residency commitment on this site. We would rather say that than publish a number we cannot stand behind. If you need a contractual commitment, talk to us directly.
Can we use our own domain?
Yes. Every application keeps its permanent platform address, and your domain sits on top of it. You point a DNS record at the edge, and Cisely issues and renews the certificates.
How do we know it works?
The toolchain turns every statement the model makes about behaviour into an obligation: each guard, policy, validation rule, typed error and isolation boundary. It reports how many obligations have evidence, and what is waived, by whom and until when. It refuses to call tenant isolation proven until a real deployed stack proves it. We walk you through the real report in a review.
Does authoring depend on you being up?
No. Local validation runs with no account and no network, so your daily loop does not depend on us. Building, generation and deployment run on the platform.
The proof
Cisely itself comes out of the Software Factory.
Our own product is a Precise application, written in Vishwakarma with the same building blocks you use. The factory builds from your business context, in Context Management, and Paroksh does the work across both.