A local workbench for bounded engagement records.
Runtime applies the workshop discipline to the place I needed it most: running a security engagement without losing the thread of scope, notes, findings, and handoff artifacts. An engagement is a local workspace: the agreed boundary of what may be touched, the assets in it, the findings as you record them. None of those records reach out to the real systems they name. They are notes about the work, held on your own disk.
Each capability in Runtime carries the mode it is allowed to run in (sim, dry_run, local_lab, or authorized_run), and the tool refuses to run a capability in a mode that capability does not declare. The checks give the same answer every time: run them again and you get the same result, with no duplicated findings, and anything that doesn’t apply is reported as skipped rather than quietly dropped.
A release with a clear artifact trail.
Runtime ships with the package, a checksum manifest, and a release record: the package identity, source revision, Python version, platform, and digests in one file. Before you run it, you can see what was built and which files belong to the release.
Five files in the release: the wheel, the source archive, a portable bundle, a checksum manifest, and the release record that ties them together.Don’t take its word that it’s healthy and bounded. Ask it.
Runtime can check its own install and report exactly what it is, in plain output: the version, the capabilities it carries, where it keeps state, and that it’s ready. Real output, nothing edited.
$ python -m orca --version orca 1.0.0 # doctor: a self-check that says what this install actually is $ python -m orca doctor ORCA doctor profile: local ready: true check: package ok version=1.0.0 capabilities=27 check: registry ok capabilities=27 check: modules ok descriptors=5 check: state_dir ok .orca/state check: artifact_dir ok .orca/artifacts
It tells you what it is before you ask it to do anything: a known version, a fixed set of capabilities, and a local place it keeps its state. No surprises, and nothing reaching off your machine.
Real output from python -m orca doctor on a clean install: Python 3.11+, v1.0.0, 361 tests, CI green on 3.11 and 3.12. The everyday flow is engagement (open a workspace) → assess (run the local checks) → report (write the Markdown report) → bundle (a portable ZIP), and orca demo create builds a whole worked example in one command. Honest limit: the assessment checks are deliberately small and local, just seven metadata-only checks and three local module types. This is a local runner for an engagement, not a vulnerability scanner, and it is by design unable to be one.
What it is, and what it is not.
Runtime is a local-first command-line runner for authorized assessment work: v1.0.0, 361 tests, with checksums and a release record on every build. Its whole safety model is one sentence: it is local and metadata-only (it reads descriptions of things, not the things themselves), and it has no way to reach a target. It does not scan, probe, resolve, connect to, or attack anything; the records you keep are notes about the work, not connections to the systems they name; and it refuses to run a capability in a mode that capability does not declare.
It cannot touch the target. That isn’t a setting. There is no capability in it that reaches off your disk.
The honest edges: the set of built-in checks is small on purpose, because this is the structure-and-bookkeeping layer of an engagement, not the part that finds the vulnerabilities. Its public surface is the release-safe contract, docs, and artifact envelope; owner-specific material stays private and local. It needs Python 3.11 or newer. It is the workbench I actually run my own engagements from: bounded, local, and able to tell you what it is.