Future work: reusable oracles hosted in Starforge (registry + on-demand invocation for model-checking)

[mzargham]

Read this with sibling issues A and B

This issue is the third of three (A, B, C) that together describe the path from this demo to a Starforge-resident production substrate for Planetary Utilities' team. They share one assumption: that the reader has already watched the marimo notebook (notebook.py) — it is the narration of the value prop (reproducibility + real-time auditing + evidence chains + human attestation as the only judgement boundary). The three issues describe what PU would build, host, and offer to extend that value prop. They do not require understanding the demo's inner workings; the notebook carries that load.

• A (#7) — host a Docker registry inside Starforge.
• B (#8) — bring externally-hosted RIME compute + the operator cockpit (rime-backend-demo) into the proof chain.
• C (this one) — synthesize A + B into a Starforge capability: package the demo's verification engines (oracles) as registry-hosted images that Starforge invokes on-demand whenever a model-checking activity needs them.

The collective shape: A gives Starforge a registry. B gives Starforge a compute substrate. C gives Starforge a catalog of reusable verification capabilities those pieces serve.

What an oracle is, in one line

In the demo, an oracle is a packaged computational engine that produces evidence about a model — e.g. a SymPy proof script that proves stability margins, or a scipy ODE simulation that produces settling-time data. Evidence is not the verdict; an oracle does not "approve" anything. A human reviewing the evidence is the only judgement boundary. The oracle's job is to be deterministic, content-addressed, and reproducible by anyone, anywhere.

The marimo notebook walks through two oracles (symbolic + numerical) running against a satellite ADCS model. The point of this issue is to take that pattern and make it Starforge-native: an engineer in Starforge picks an oracle from a catalog, points it at their model, and gets back evidence — without writing the oracle, hosting the image, or managing the compute.

What Starforge would offer (the ask of Planetary Utilities)

Three capabilities, in increasing order of integration:

1. A registry of oracle images

Builds on Issue A. Starforge hosts the registry; oracle authors push pre-built Docker images that bundle:

• a deterministic computation (symbolic, numerical, structural, whatever fits)
• a declared input contract (what RDF / JSON shape the model needs to expose)
• a declared output contract (what evidence shape it produces — content hash, RDF triples, summary)
• provenance pins (the git ref the image was built from; the base image digest; the build-context hash — analogous to rtm:DockerImage properties in this demo)

The registry is browsable; each oracle has a stable IRI in Starforge (e.g. starforge://oracles/<author>/<oracle>:<version>).

2. On-demand invocation

Builds on Issue B. A Starforge user with a model:

• picks an oracle from the catalog
• supplies their model (as RDF, or by URI to a Flexo record)
• Starforge spins up the oracle's image, runs the computation, captures provenance (image digest + container ID + input model hash + output evidence hash), writes everything back into the user's Flexo project as rtm:Evidence linked to the model

The user never touches the Docker daemon, the image bytes, or the compute substrate. They get back evidence that links cleanly into the same proof-chain structure the demo's notebook narrates.

3. A model-checking workflow that uses the catalog

Builds on 1 + 2. The model-checking activity in Starforge — whatever shape it takes — gains "invoke an oracle" as a first-class step. The activity records which oracle was invoked, against what model, producing what evidence. The provenance chain extends naturally: model in Flexo → oracle invocation in Starforge → evidence node in Flexo → human attestation in Flexo, with every step content-addressed and replayable.

Value prop for Planetary Utilities

Three reasons PU would want to build this:

1. Differentiator vs. plain RDF triple-stores. Flexo already stores RDF. The opportunity is to be the platform where engineering verification runs, not just where engineering verification artifacts are stored. A hosted oracle catalog is the simplest version of that capability and a wedge into the broader market.
2. Recurring usage per project, not per organization. Every engineering project that uses Starforge will invoke oracles — many times per design iteration. Hosting them creates structural lock-in around compute-as-a-service for verification, with predictable usage growth that scales with project complexity.
3. Compounding catalog effects. Each oracle that lands in Starforge's registry becomes usable by every project on the platform. Early oracle authors (DSG, JPL, JAXA partners, INCOSE working groups) become the seed of a network effect that's hard for any single-tenant alternative to match.

What's not being asked

To be explicit about boundaries — PU would not need to:

• Understand the demo's inner workings (the notebook carries that load).
• Build the oracles themselves (that's the responsibility of authors — DSG is one of them).
• Maintain a UI for picking oracles in the first version (a JSON API + the rime-backend-demo cockpit fronts the user-facing surface).
• Provide judgement/attestation tooling (that's the human boundary; out of scope).
• Replicate any of the demo's specific verification logic.

The ask is for the substrate, not the content.

Acceptance criteria (when this becomes its own WP, post-WP4)

Not a commitment now; surfacing what success looks like to make the ask legible:

• A small Starforge surface (REST or gRPC) for listing oracles by capability, fetching their input/output contracts, and invoking them with a model reference.
• The oracle registry shares auth with Flexo (one FLEXO_TOKEN, scoped appropriately).
• An invocation returns an evidence record that drops cleanly into a Flexo branch as RDF — no glue code on the caller's side.
• At least two reference oracles published into the registry by DSG (the symbolic + numerical pair the demo notebook uses).
• The provenance chain from this demo's WP4 extends end-to-end through Starforge: a model in a Flexo project → an oracle invocation in Starforge → evidence in the same Flexo project → human attestation — replayable, content-addressed, audit-grade.

Coordination

This issue is the synthesizing ask. Read A and B first — they're the building blocks. C is the offer that makes hosting both of them strategically coherent for Starforge's roadmap, not just operationally useful for the ADCS demo.

If PU's team wants to discuss any of A / B / C, the natural entry point is the marimo notebook (notebook.py in this repo, also rendered to output/notebook.html) — it's the artifact that makes the value prop concrete without requiring a code review.

References

• This repo: DynamicalSystemsGroup/ADCS-lifecycle-demo (protocol research demo, marimo notebook).
• Sibling issue A — #7 Docker registry coordination with Planetary Utilities.
• Sibling issue B — #8 Future work: exercise externally-hosted RIME services (cross-link with rime-backend-demo).
• DynamicalSystemsGroup/rime-backend-demo — operator cockpit + frontend.
• Roadmap WP4 — Three-remote architecture made real, "Non-goals" section (what the demo deliberately stops at; this issue picks up where it leaves off).
• Future-work item Rename ValidateShapes step IRI to VerifyShapes (with Flexo + audit migration) #6 (CLAUDE.md) — production Flexo deployment, of which this is a natural extension.
• Slide context: openbee_dsg_opener.pptx (slide 3 — software supply chain as a layered stack with feedback; slide 4 — MOSA / vendor-neutral spines).

[johannes-johannes]

I just want to add that i love this. This is spot on @mzargham ! Thank you!