020 — Output verbosity and significant digits

23 October 2026. Implementation checkpoint: 2efc810 — Add shared output settings and scientific result verbosity. This record distinguishes contained qualification from the subsequent managed service and API offering delivery. No new live model interpretation or browser transaction was used.

Decision and rejected alternatives

The user requested selectable result detail alongside significant digits, using the established names low, medium and max. Proposed compact/full names and aliases were rejected. One shared output fragment contains both choices; defaults are medium verbosity and 4 significant digits. The small interpretation record stays at every level: it explains input selection without a transcript. Hiding it would save little while removing useful scientific provenance.

LevelScientific and supporting fields
lowEvery H/C prediction, full ordered atoms, source/record/member correspondence, generated-atom and H-parent mapping, generation provenance, conversion, coverage, model/runtime identities, interpretation record, warnings and limits.
mediumLow plus the prepared request and admitted float32 coordinate array.
maxMedium plus execution.tool_sources, the per-file software manifest.

Low does not preserve a self-contained geometry for supplied or generated input. A digest identifies bytes; it cannot recover them. There is no post-publication detail upgrade or promise to regenerate an identical geometry. Prepared decimal-to-binary64 coordinates and admitted float32 coordinates can differ, so medium retains both rather than calling either redundant.

Magnet provided vocabulary and presentation precedent, not NMRNet field policy: strict three-level enum, scientific offering description, and interpretation metadata retained across tiers. The offering copy was revised through independent chemistry-reader teach-back and source review. The catalogue summary links to the detailed scientific guide.

One fragment, existing owners

"output": {"verbosity": "medium", "shift_significant_digits": 4}

Core owns only the enum and exact string parser. NMRNet's immutable OutputSettings owns defaults, precision and JSON admission. Missing fields receive defaults; explicit null, booleans, unknown fields, aliases and invalid values are rejected. All three interpreter preparation tools use this parser before source acquisition or native allocation. Direct coordinate JSON uses the same object at its binding boundary.

The direct path strictly decodes the entire bounded input before separating output preferences. Duplicate keys cannot disappear during that separation. Original source identity covers the complete verified bytes, including output; scientific request identity covers the derived coordinate request. Native prediction still admits only atoms, coordinates and coordinate_unit. Configured production interpretation remains the deployment path; this does not introduce a public interpreter bypass.

Sources at the implementation checkpoint: core vocabulary, immutable settings, direct binding, preparation capabilities, strict decoder and unchanged native field admission.

Scientific admission, capacity and replay

Result schema v2 records the complete output choice. All scientific outcomes are validated before publication projection. Significant digits (1–17) affect published numeric values only; protected unrounded observations remain unchanged. Precision is not an accuracy claim, and JSON numbers do not preserve display trailing zeros.

The public reservation and final encoding use the same projection under the existing 786432-byte limit. Full prepared identity and scientific evidence remain subject to their existing 262144-byte ceilings. Native framing and resource limits are unchanged. A smaller public view never bypasses these independent gates. Existing terminal bodies retain their exact bytes and original schema during store reopen and lost-receipt replay.

Sources: _public_envelope, ResultPlan, rounding and admission; prepared identity and private evidence admission. The pure public-sizing test deliberately uses an oversized synthetic manifest; it is not evidence that this manifest could pass private persistence admission. A separate Session test refuses oversized private identity before worker work.

Focused contained qualification

The controller image built offline from checkpoint 2efc810 is sha256:f5a315c335186cc6b21a099d3fbe7c2d2becbb207f588d119a159cfbec69851f. make test/integration/provider-runtime passed all 4 installed-image tests, including isolated imports of the binding that consumes the enum. Source-mounted unit tests and installed-package/image tests are separate proof. These checks do not qualify new numerical accuracy, real-model semantic interpretation of each verbosity request, or deployment delivery. No paid Job/model call or unchanged scientific accuracy rerun was needed.

Test sources: tier preservation and public sizing, direct input refusals and hashes, private limits and publication, successive Jobs and replay.

Qualification belongs at the API boundary

The user challenged the browser tests encountered during this change. This provider repository should qualify API behavior and scientific results; browser credential import, GUI controls, downloads and submission flows belong outside its scope. The GUI JavaScript harness, browser proxy, launcher, three Make targets, selectors and browser-only resource profile were removed in 43b613f — Keep provider qualification at the API boundary. No sibling repository was edited.

The existing API qualification retains scripted pasted input, real-model pasted input, SMILES, multiple SMILES conformers, XYZ Uploads and SDF ZIP Uploads, plus explicit SDF reservation resume. The fixture is now tests/fixtures/preparation/api_sdf_zip.json, without an old-name alias. Exact supplied science, archive/member correspondence, credential separation, bounded clocks, source capture and no automatic mutation retry remain. The previous GUI comparator is cited only as pinned port provenance in the API comparator. Sources: API qualification owner, retained API composition cases. Dated evidence in record 003 remains historical.

Focused offline checks after removal: API staging/composition 16 passed; host launch/lifecycle 27 passed; operator-input repository checks 25 passed. Independent source audits found no remaining actionable issue in the retained API and host ownership paths. These are recording-port checks, not new API transactions or browser qualification.

Managed service recovery and delivered offering

The existing local service had stopped after the API refused a signed inventory read whose acceptance window had closed. The API explicitly states that both authentication_window_closed and signature_expired requests did not execute and may be freshly signed. Invalid credentials, future-dated signatures and reused nonces remain distinct. Authority: API timing-refusal meanings; API explanation tests.

ab56e80 — Recover expired signatures through existing API operation owners admits these two complete, correlated refusals only after the original transport retires. It adds no automatic API send: existing GET, Hello, retained START/progress and terminal permissions still own routes and bodies. Inventory and Hello retain capped jitter/backoff, per-request deadlines and shutdown responsiveness. An initially proposed single-refresh cap was removed: repeated timing refusals do not prove permanent clock failure. Attempt observations and retained writes keep their existing finite recovery windows. No grant-issuance or scientific retry is added.

Tests-first qualification: 65 API tests and 48 service/recovery tests passed. Local TLS witnesses exercise both timing codes, three refusals followed by recovery for inventory/Hello, and configured bounded START/completion replay. They verify fresh signatures, unchanged retained write bodies and one execution of the recording scientific worker. Persistent refusals remain responsive to explicit stop, without allocation or inference; invalid-authentication tests retain their refusal behavior. Sources: can_refresh_signature and existing operation predicates, signed receiving witnesses, persistent refusal and stop witnesses.

Before startup, the original host's retirement was confirmed and the maintained offline stopped-store inspection found no unresolved records. Only the two public description fields were updated in the operator configuration; all other parsed values and the private mode were preserved. The admitted configuration SHA-256 is baa22f26ddbd26ca8cd41a8201a4def55bbd46a1a8fa04a4a674ad6124c6e9ad.

The new managed invocation 47f064a8bc4245f09339293d5ce87645 was active, running and enabled when observed. Its controller was independently observed running as UID/GID 1000:1000 with image sha256:02715c4ffa55a9d13377c7a96707732c83ea3cd3558b7b1cf173363662ad8f84. All 4 installed-runtime tests passed for this image. This is local service evidence, not proof of an operating-system reboot or an external deployment.

At 2026-10-23T11:12:54Z, one signed public API directory GET returned the managed provider's 995-character offering and provider description, both exactly equal to the reviewed operator values. The API reported the last Hello at 11:11:57.931515Z. The canonical HTTPS origin/port was preserved; the local publication used an explicit loopback mapping, not a DNS claim. No Job was created and no model or scientific request was submitted for this delivery check.

Compact functional receipts, without credentials or process-log exports, are retained locally at .work/qualification/service-output-ab56e80. SHA-256 of its sibling manifest service-output-ab56e80.sha256: 0be9e7d6afce29db0a481288b0dde19e06ae5dc05f6ae60e7c0f95c814f03a2b. Received public directory bytes: 8e9580a532468b8ec3b53f1c91d00f11088a4c0cb7fecaa08f24096e9548c96d; compact delivery receipt: f649e64ca2edd7e01297a12cfe759b9cdace80b411cf4c3fbe412719f5833259. These observations do not establish that a real language model has correctly selected every new verbosity preference; that remains distinct from scripted tool qualification and actual offering delivery.