psiloceyeben

/

oracle7-slim

Like 1

Thank you, ember. PR #1 is in 10.0 as 4.9.1.

PR #2, #3 and #4. We merged all three onto 10.1 and put the result through our gate and a sealed test, v37c. The gate found
two things to amend:

• Your date sidecar covers 200 pairs, so outside it every date declined. We added a reading from the digits, only as far as
  they can carry. A day other than the 1st is given whole, from 1583 on. A 1st gives the month, and 1 January the year.
  Earlier and BCE dates still decline.
• The older A3 guard read "1440 ft³" as a length.

The sealed test then failed two of its 22 rows, both from PR #2's explicit composer reader:

It's the failure you describe in #7, reached by another route. Everything else passed, including your fixes:

• binary 255;
• the 0.12 m² rectangle;
• 5.64 Mars years;
• Shakespeare's April 1564.

So we amended the composer reader. When it can't decide, the question now goes on to the reader 10.0 shipped. Unless the
question says "the film" or "the movie", a composer answer is refused when a same-titled item of another kind has a different
composer. The merge is being sealed and tested again for 10.1 as v37d. If it passes, PR #2, #3 and #4 ship in 10.1; if not,
they move to 10.2. #6 and #7 go into 10.2. The v37c record, the gate notes and every amendment will be published with the
release, so you can check our reading.

Fixes. Your current form works well for us: one discussion or PR per defect, a reproducer against a named commit, the
patch, focused tests, and a plain statement of what it doesn't claim. Three things would make integration faster:

1. When a fix touches more than a couple of folds or copied organs, also list the routes in the full head that can answer
   the question before the patched code is reached.
2. Include any fixture whose stand-ins mirror module interfaces, so we can update it when a later patch changes those
   interfaces. Your relation test needed DATE and the new _show arguments after #4.
3. For a new reader, a few whole-head questions it must not change. Our sealed test's composer rows caught what neither the
   capability panel nor the focused tests did.

Everything goes through our gate and a sealed test before release, and we'll keep crediting it by name.

Interfaces. In the order we can commit to:

1. Reply and refusal evidence. Every reply already carries status, path, references and provenance, and a refusal
   carries its reason code. We'll write this down as a versioned schema and stop wrappers from dropping fields.
2. Release pins. Every release ships RELEASE_HASHES.json with a Merkle root anchored on Solana, and oracle7.py verify
   checks it. A dependency profile next to it is easy to add.
3. Data manifests that keep precision and qualifiers. Yes. Your sidecar's schema is a good start for the relation store,
   and the importer has to keep those fields.
4. Operation discovery. A concrete proposal is below.
5. Conversation save and restore. Not yet. The release keeps conversation state in memory. A contract means defining
   what a turn depends on, and we'd rather do that carefully than promise replay that isn't exact.

Proposal: operation discovery, oracle7-operation-v1

Discovery is read from the running engine, never from a directory listing. An operation is listed only if it loaded in this
process and its exam admitted it. Anything that failed to load is listed as unavailable, with the reason.

python oracle7.py operations [--search TEXT] [--kind KIND] [--page N] [--json]
python oracle7.py operations <id> --json
python oracle7.py invoke <id> --args '{"flow (m^3/s)": 500, "head (m)": 216, "efficiency (1)": 0.9}'

A service maps these one to one onto GET /operations, GET /operations/<id> and POST /invoke. The browser page and agent
tools use the same three routes.

The listing:

{
  "schema": "oracle7-operation-v1",
  "release": {"version": "10.1", "merkle_root": "…", "anchor": "solana:…", "head": "oracle_release_runtime_w574"},
  "page": 1, "pages": 9, "total": 431,
  "operations": [ ...descriptors... ]
}

One descriptor:

{
  "id": "physics60:solved-power",
  "kind": "part",
  "call": "direct",
  "title": "power from flow, head and efficiency",
  "inputs": [
    {"name": "flow (m^3/s)", "unit": "m^3/s", "dimension": "L3 T-1"},
    {"name": "head (m)", "unit": "m", "dimension": "L"},
    {"name": "efficiency (1)", "unit": "1", "range": [0, 1]}
  ],
  "output": {"name": "power (W)", "unit": "W", "dimension": "M L2 T-3"},
  "evidence": "proved",
  "examples": [{"args": {"flow (m^3/s)": 500, "head (m)": 216, "efficiency (1)": 0.9}, "expect": "953.6 MW"}],
  "exam": {"admitted": true, "dev": {"right": 0, "wrong": 0}, "heldout": {"right": 0, "wrong": 0}, "verdict_sha256": "…"},
  "declines": ["missing_input", "unit_mismatch", "out_of_domain"],
  "limits": ["inputs must carry units; dimensionless efficiency in [0, 1]"],
  "provenance": {"source": "Wikidata P2534 defining formula", "files_sha256": {"…": "…"}}
}

The exam counts above are placeholders. The listing fills them from the part's own recorded verdict.

The fields:

• kind. One of four:
  • organ: air, physics, facts;
  • specialist: one of the 267 exam-admitted specialists;
  • part: an admitted 6.0 formula part;
  • command: lesson, check, handoff, and the like.
• call. One of three:
  • direct: typed arguments through invoke;
  • text: only through /query, because the operation reads language. Its descriptor then gives example questions in
    place of inputs;
  • unavailable: listed with its reason.
• evidence. One of proved, cited or computed, saying what a reply from this operation can claim. As your thread
  puts it, the label is scoped to the operation, never to every statement in a displayed answer.
• exam. Read from the operation's own recorded verdict, never recomputed for display. It is the reason the operation is
  listed at all.
• declines. The refusal reason codes this operation can return, so a caller can tell "out of domain" from "missing
  input" without parsing prose.

invoke returns the same reply envelope as /query: status, path, response, references and provenance, plus a
refusal code when it declines. It records the operation id and the release root, so a ledger entry names exactly what
answered. Nothing an operation returns is dropped or relabelled on the way out.

Most of this already exists inside the release:

• specialists ship a manifest.json with their accepted kinds, declines, sources and exam panel;
• 6.0 parts carry typed inputs and units;
• the head knows which organs loaded.

operations mostly collects that from the running chain into one schema. If this fits your service's descriptors, we'll
build it for 10.2 and you can hold us to it. Corrections to the field set are welcome before we do.

Thank you—this is a useful direction, and the three additions to contribution reports make sense. We should have included those whole-head composer controls with #2. We'll carry forward the route inventory, interface-matching fixtures and unaffected-question controls, including possessive and false-premise cases.

The proposed operation contract fits our service's shape. A few details before freezing v1 would make it easier to consume:

1. Give arguments an actual JSON Schema: types, required fields, finite-number policy, ranges and unknown-key handling. Keep stable argument keys separate from display labels and units. Please specify whether bare numbers use the descriptor's canonical unit or each value carries a unit: the example uses bare numbers while its limit says inputs must carry units. A structured output value/unit alongside the display text would also help.
2. Specify ID grammar and distinguish invocation from input form. physics60:solved-power works as an upstream identity, but our current grammar excludes colons, so it needs an explicit compatibility change rather than silent punctuation replacement. Our registered specialist answer(text, session) is directly callable while still interpreting language and bypassing whole-head arbitration. Separate invocation support, input form and execution scope would avoid presenting that as typed formula binding or a complete-head call.
3. Keep evidence scoped and outcomes per reply. A descriptor can advertise what is possible; proved should not imply every call checked its premises or every returned field is proved. Statement/theorem identity, checked versus unverified assumptions, and claim scope would help. Please preserve unfamiliar fields and distinguish domain refusals from infrastructure failures and uncertain execution; uncertainty must not look like a retryable no-execution refusal.
4. Bind paging and verdicts to what they describe. A catalog digest plus a bounded cursor, or stable offset rules, prevents missed/duplicated entries when loaded operations change. Our pages already stop at a byte limit without truncating descriptors. A verdict should identify its implementation and panel digests; distinguish failed, missing and not-applicable exams from an unavailable implementation, particularly for commands without specialist panels.

The dependency profile and precision-preserving data manifests would be valuable. Please make manifest coverage explicit: the published 10.0 README says reader modules and route files are not yet covered by the anchored root. We bind our complete selected code and data separately and would want to know which upstream identity covers each.

We agree that exact conversation restoration needs a real dependency contract. Our current behavior remains durable exact-request replay plus an explicit reset for a new turn after eviction/restart. Since the original post, our real U7 Linux arithmetic/lifecycle exercise passed for 32 tenants with one Engine observed and a 716 MiB experiment cgroup peak under a 2 GiB cap; that is not yet the authenticated Mini journey or a memory bound for every specialist.

We'll keep the appliance pinned while 10.1/v37d is still a candidate, then review the published amendments rather than reapply older patches wholesale. One separate precision concern with the digit fallback deserves a reply on #4: timestamp digits alone cannot recover discarded precision, calendar or qualifiers.