Questions
The things people ask before they commit.
Including the ones with uncomfortable answers. Where something is not finished or not yet promised, it says so — you would find out in the security review anyway, and finding out here is cheaper for both of us.
What this actually is
The questions that decide whether to keep reading.
- Is this a code generator?
- It generates a backend, a schema and its migrations, an API and its contracts, and typed clients — but that is the last stage, not the product. The point is that what it generates is derived from the same model your mission, expectations and strategy live in, so the software cannot drift from what it was for.
- What is the difference between Concise and Precise?
- Concise is the business context: who you serve, what you intend, what you promise, and how you will know the promise was kept. Precise is the application that answers that intent, and everything from a validated model through generated software to a running, addressable service. Neither is worth much alone — context nobody builds against is shelfware, and software built against unverified context is the problem the platform exists to solve.
- Do I have to read generated code to stay in control?
- No. You direct and judge; the agent builds. The Workshop gives you eight views of the model — tables, operations, architecture, flows, contracts, coverage and the running app — and Source is there when you want it, not because you need it.
- Who is this for?
- People who hold a clear vision and want to direct it themselves, whether that is a founder turning a conviction into a company or an architect inside a large organisation who can see the whole system before it exists. It is not for handing over the vision and hoping.
Working with the agent
What Paroksh can do on its own, and where it has to stop.
- What can the agent change without asking me?
- The approval requirement belongs to the operation rather than to the agent, so it cannot be escaped by a different caller. Risk is graded: an additive, high-frequency action such as recording a measurement proceeds unattended, a consequential state change needs a confirmation, and a destructive one can require two people. When Paroksh needs a decision the request is modal, cannot be dismissed, and the agent is genuinely blocked until you answer.
- If the AI writes it, how is any of it deterministic?
- Because the agent does not write the system. It authors a model, and a compiler derives the backend, schema, migrations, contracts and clients from that model — the same model producing the same system every time. What you review is a declaration you can hold in your head rather than a diff of thousands of generated lines, and a suggestion that is wrong can only be wrong in ways the language can express.
- Does anything the agent drafts count straight away?
- No. Everything it drafts arrives as a draft. You read it, change what is wrong, and activate what you agree with — so the model holds what you actually believe rather than what was plausible. Every write it performs is done as you, through the same permission-checked operations you would use yourself.
- What happens between sessions?
- The agent does not persist; the work journal does. Decisions, memories, lessons, sessions, checkpoints and runbooks anchor to the same nodes the rest of the model uses, so a new session starts by reading what the last one concluded rather than rediscovering it.
Running what you build
Where it lives, what we operate, and what we do not promise yet.
- Where does the application actually run?
- On managed infrastructure we provision per application: its own database with separate owning and request-path roles, its own event-bus and cache namespaces, its own buckets, a dedicated API gateway behind the shared edge, and certificates issued and renewed for every host. You do not assemble or operate any of it. Between requesting a publish and the application serving there are no operator steps.
- How are we isolated from your other customers?
- That is two questions and they have different answers. Between applications, the platform separates you: a separate physical database, credential-scoped event-bus and cache namespaces, separate buckets, a separate compute namespace. Inside your application, your own customers are separated by row-level security generated from the isolation axes your model declares. Physical names are allocated by the platform from a durable identifier, so no project name can collide with or be used to guess at another customer’s resources.
- What uptime or scale do you commit to?
- None yet, and we would rather say so than publish a number we cannot stand behind. The path from model to running application is built and demonstrated end to end, but the packaging around it — plan, price, placement and any service commitment — is still being settled. If you need a contractual guarantee today, that is a conversation to have with us directly rather than a claim to read off a page.
- Can we use our own domain?
- Yes. Every application keeps its durable platform host, and a custom domain layers on top of it, so branding never becomes an identity change. You point a DNS record at the edge and certificates are issued and renewed automatically.
Ownership, exit and review
The questions a procurement or security review will ask.
- Who owns the code, and can we leave?
- You do, and yes. Initialising a project adds no git remote and stores no git credential — your origin is entirely yours. Generated code is delivered to a branch of your own repository. What you end up with is an ordinary production application on standards-based artifacts, with no runtime of ours to keep in your stack.
- How much hand-written code ends up in the system?
- Imperative code lives only in declared seams, which means it can be counted rather than estimated. In the platform’s own reference application those seams are roughly one percent of what the model generates. The number matters less than the fact that it is knowable.
- How do we know it works?
- The toolchain derives one obligation per falsifiable statement the model makes about runtime behaviour — every guard, policy, validation rule, typed error and isolation axis — and reports how many have evidence behind them, which single constraint is binding, and what has been waived, by whom, until when. It also distinguishes what static analysis showed from what ran in memory from what was proven against a real deployed stack, and refuses to call tenant isolation proven until the last of those exists. We do not publish the scores: they measure how far a verification programme has got rather than how good a product is. Ask in a review and we will walk you through the real report, including the empty parts.
- Does authoring depend on you being up?
- No. Local validation runs with no account and no network, so the loop you spend your day in does not depend on us being reachable. Building, generation and deployment do run on the platform.
What is not finished
Worth knowing before you sign up rather than after.
- How finished is it?
- We build on Cisely ourselves. The platform reference tracks its own gaps openly: a session cannot yet see a published application’s logs, metrics or incidents, and some modelling mistakes still pass validation silently. We would rather you knew that before you signed up than after.
- What happens when I change my mind?
- Change the model and everything derived from it follows. A rename is made once. Schema changes are derived by comparing the model with the database rather than hand-written, and API contracts stay compatible with clients already deployed.
- Does this replace our existing tools?
- Not on our say-so. It covers a lot of ground that project tracking, documentation and architecture tools cover today, but whether it replaces any of them depends on your scope and your integrations. Anyone who tells you otherwise before seeing your setup is guessing.
Something here not answered?
The enterprise door on the way in reaches a person, not a queue. Ask the awkward version of the question — it is the one worth our time and yours.