Ask something. CorvinOS builds the analysis plan, runs it in the background across your data sources, and returns the findings as files you can open, share, or schedule — while the conversation stays uninterrupted.
Instead of producing one answer and stopping, the Compute layer keeps running until the result meets your standard. It divides the problem, assigns pieces to parallel workers, checks every result, and tries again when it falls short — automatically.
When a sub-problem turns out to be more complex than expected, the system spawns its own mini-team to handle it. Each branch works independently, within a shrinking budget, so the whole run stays bounded and predictable.
Before a finding is accepted, it passes five independent checks: Is the deliverable complete? Is it original? Does it hold up to critique? Does it meet your declared metrics? Only results that clear all five move forward. Failed checks trigger repair, not failure.
Far from the target, the system deploys more workers in parallel to explore faster. Close to the target, it focuses on refinement. This concentrates your compute budget on the parts of the problem that are still unsolved.
For data classified as CONFIDENTIAL, the system automatically switches to a fully local AI — no cloud, no egress. Ordinary analysis uses cloud models. The routing happens silently, enforced at every spawn, based on your data classification.
If a worker discovers mid-analysis that it needs a capability that doesn't exist yet, it creates the tool and uses it immediately — no restart, no human in the loop. When the run finishes, the custom tools are bundled into the package, ready on any system that installs it.
Describe what you want to find out. The system builds the entire plan, executes it across your data, and delivers the results as files you can open, share, or schedule — while you're free to do something else.
The coordinator reads the goal, dispatches work to parallel workers, and reviews results — but never touches your data directly. Workers run in isolation from each other and from the coordinator's context. Only clean summaries flow back up. After each round, the coordinator decides: push further, declare success, or stop cleanly.
Connecting to a database does not mean your data is visible to the AI. It receives only a reference code and a structure description with personal details removed. The actual records stay behind the firewall, touched only by isolated workers that cannot communicate with the AI directly. Database passwords and keys are never in a prompt, a log, or an audit record.
Instead of your data, the AI receives an opaque code. The actual records are accessible only to isolated workers — not to the conversation, not to any log.
Credentials are passed directly into the sandboxed worker at startup — never written to a file, never included in a prompt, never stored anywhere a later process could read them.
If the data is marked sensitive and the right key is absent, the system replaces the content with a placeholder. The run pauses cleanly — it never risks exposing confidential data to recover from the situation.
After each attempt, the system measures the quality of the result against five dimensions. The coordinator reviews the scores and decides whether to continue improving, accept the result, stop because progress has stalled, or abort because quality degraded. The process is self-correcting rather than single-shot.
convergedTarget reached, result accepted.
continueNot there yet — another round starts automatically.
plateauProgress stalled — the system stops rather than spinning.
regressionQuality dropped — the run stops to protect what was already produced.
If a worker realizes mid-analysis that it needs something that doesn't exist yet — a custom formatter, a domain-specific calculator, a data normalizer — it creates the tool and uses it immediately. No human is required to intervene. The run continues, now more capable than when it started.
Any tool created this way can also be used as the target for optimization — the system will tune parameters until it finds the combination that makes the tool perform best.
Workers can create tools on the fly. As soon as a tool is created, it's available to every subsequent worker in the same run — no restart, no wait.
When you export the run as a package, any tools created during it come along. Install the package on any CorvinOS system and the tools are immediately available.
Tell the system to maximize or minimize what your tool produces. It will run hundreds of parameter combinations, evaluate each one, and converge on the best — automatically.
When the analysis succeeds, the system saves the entire run as a portable package — ready to share, install, and repeat.
A successful run doesn't disappear after you close the conversation. It becomes a package — everything needed to reproduce the same analysis, on any system, with a single install command.
discovered-a7f3b2c1.awpkg
├── manifest.yaml # id, version, permissions, acs_provenance
├── workflows/
│ └── discovered-a7f3b2c1.awp.yaml # the AWP workflow DAG
└── provenance/
├── acs_manifest.json # run_id, iterations, workers_spawned, duration
├── gate_results.json # quality gate evaluations per iteration
└── quality.json # aggregate_score, evaluation count
No user data. No raw database content. Only the workflow structure and run metadata.
The workflow is frozen exactly as it ran. Deploy it on a schedule and you get the same analysis, the same way, indefinitely.
awpkg export --mode dag
The shape of the workflow is fixed, but the execution adapts. Useful when the underlying data changes and you want the analysis to stay current without rebuilding from scratch.
awpkg export --mode template
The package includes a full record of how the result was produced — iterations, quality scores, every gate evaluation. You can always trace a finding back to exactly how it was generated. Apache-2.0 license is applied automatically.
# Any CorvinOS instance awpkg install discovered-a7f3b2c1.awpkg # Or from a URL / shared path awpkg install https://share.example.com/discovered-a7f3b2c1.awpkg
# Deterministic execution workflow run com.corvin.discovered-a7f3b2c1 # List installed packages awpkg list # Inspect before running awpkg inspect discovered-a7f3b2c1.awpkg
Discovery and repeatability are two different needs. Use the exploratory mode when you don't know the steps yet, switch to the deterministic mode once you have a proven workflow you want to run on autopilot.
You describe what you want to find. The system figures out the steps, tries different approaches, and adapts as results come in — you don't need to know the method in advance.
orchestration.engine: delegation_loop
Once you know the right process, run it on autopilot. Every step is defined, the path is fixed, and the results are identical each time — on a schedule, or triggered by an event.
orchestration.engine: dag
When an exploratory run produces something worth repeating, you don't have to rebuild it. Package it, share it with a colleague or a second deployment, and run it again — no re-configuration, no manual steps.
Describe the goal. The system builds the plan, runs the analysis, and delivers findings as files.
One command captures the entire workflow — steps, tools, and quality checks — as a portable file.
Send the package to a colleague or deploy it on another system. One install command is all it takes.
The same analysis, on a schedule, with the same quality guarantees — indefinitely.
Every compute worker runs on your own machines — on-premises, your own cloud VMs, or wherever your databases already live. CorvinOS never requires data to travel to a third-party service.
Workers run on your own servers or cloud VMs. No third-party infrastructure is required to process your data.
Add more worker instances to handle bigger workloads. Jobs are distributed automatically — no manual scheduling.
Analysis runs against data sources inside your perimeter. Results flow back to the conversation — the raw data never leaves.
Packages install on any CorvinOS deployment. Move a workflow between environments without rebuilding or reconfiguring.
Worker queues, results, and artifact stores are sandboxed per organization. One team's analysis cannot touch another's — by design, not policy.
Each compute spawn is checked against your data classification and network rules before it runs. If the check fails, the job stops — it never proceeds on a guess.
For most questions, you don't choose a strategy — the system picks for you. But if you know the shape of your problem, you can pin one. All three can run as part of a larger pipeline.
Checks every possible combination. Use this when missing an answer is not an option and you need complete coverage of the parameter space.
Samples the space broadly without trying every point. Reaches good results quickly, even in complex spaces with many variables.
Learns from each attempt and focuses subsequent effort on the most promising directions. Reaches good results with far fewer total evaluations.
Every compute run, every result, every failure is written to a log that cannot be altered retroactively. You can trace any finding back to the exact run that produced it — and prove nothing was modified after the fact.
CorvinOS is open source. Install it, describe what you want to find out, and the compute layer handles the rest — no account, no vendor dependency.
View on GitHub →