Requests and decisions
Conversations, issues, requirements, acceptance criteria and approvals retain separate meanings and clear ownership.
A conversation should not lose its meaning when work becomes a task, a code change or a deployment. Orion Workspace is the intended connected place for the people, decisions and evidence behind an application.
The experience described here is our direction for NatusAI Orion. Product scope and availability are qualified separately; it is not a release announcement.

An illustrative request shows the intended chain. Each stage produces something the next person, or authorised agent, can inspect.
Record the need. Agree which shipments, what counts as a delay and who can receive the information. Incoming feedback becomes a requirement only when accepted.
Associate the exact source change with a preview, test results and the decision to promote it. Failed verification stays visible.
Create an immutable release, record the target environment and observe whether the application meets its acceptance checks there.
Keep the resulting health, support and usage observations connected to the release. Use new evidence to shape the next improvement.
Illustrative workflow, not a live workspace or a demonstration of a released application.
Four kinds of record stay connected, so anyone reviewing an application can see why it changed, not only that it changed.
Conversations, issues, requirements, acceptance criteria and approvals retain separate meanings and clear ownership.
Documentation, source references and engineering history stay versioned and attributable. Git-backed collaboration is intended; the forge has not been selected.
Tasks, attempts, checkpoints, diagnostics, evaluations and verification artefacts are linked to the inputs and source version they concern.
A merged change, a published release and a healthy deployment are distinct outcomes, with separate records and checks.
A task should find the relevant capability and version first, then retrieve the schemas, examples or evidence it needs. A small change should not require loading an entire repository or conversation history.
Durable attempts, cancellation, checkpoints and budgets make ongoing work understandable. Summaries keep source references and freshness, while application knowledge remains visible only to authorised participants.
Compact diagnostics and precise diffs help people and agents inspect the result without hiding important correctness or permission information.


People retain control of business intent, access, budgets and operating policies. Platform visibility does not grant access to confidential application data.
The agent proposing a change cannot approve its own expanded permissions, weaken its acceptance criteria or activate its own successor.
Tell us what your business needs. We’ll help you find a practical place to start.
Or write to contact@natusai.com
