openmerit 0.1.6 → 0.1.7-preview.1

package/docs/site-domain-migration.md

@@ -0,0 +1,57 @@
+# Primary domain migration
+
+## Production migration — 12 October 2026
+
+The primary website is `https://openmerit.ai`, with the hosted terminal at `https://dash.openmerit.ai`. The domain stays registered at GoDaddy; DNS is delegated to `anton.ns.cloudflare.com` and `elinore.ns.cloudflare.com` in the existing Cloudflare account. Public TLS, email delivery, memo sign-in, and redirect cutover were verified separately.
+
+The production main site is newer than the main checkout's `demo/worker.mjs` and `wrangler.jsonc`. It includes the protected memo, D1-backed email OTP, a newer interactive demo, and the engineering article. **Do not deploy the root Wrangler configuration to production during this migration.** Doing so would replace the deployed application with older source and omit its auth bindings. The migration instead preserves the downloaded deployed application, every existing asset, all secret bindings, D1, Durable Object namespaces, and container configuration.
+
+The preserved branch `codex/main-before-terminal-2026-10-12` at `d89ebc4` contains the newer memo auth source and binding configuration. Reconcile that source with the promoted terminal branch before resuming root application deployments; do not replace the running app from this checkout simply to publish domain metadata.
+
+`demo/domain-migration.mjs` is the tested domain layer. `demo/domain-router.mjs` and `wrangler.domains.jsonc` deploy a separate Worker with service bindings to `openmerit-site` and `openmerit-terminal-preview`. This ensures all public page and asset requests pass through the domain layer even when the application serves static assets before its own Worker code. The domain router owns the public domains and redirects. The application Workers remain the owners of their content, authentication, and APIs.
+
+The main application also uses the domain layer around its preserved production entry point, with redirects disabled there. It selects the exact memo auth origin from the serving domain. Auth secrets, cookie protections, expiry, rate limits, administrator allowlist, reader records, and OTP verification remain unchanged. Cookies are host-bound: visitors must authenticate again on `.ai`; database users and reader history are retained.
+
+## Cutover contract
+
+- Website pages on `openmerit.site` and `www.openmerit.site` redirect to the same path and query on `openmerit.ai`; `www.openmerit.ai` also redirects to the apex.
+- Dashboard pages on `dash.openmerit.site` redirect to the same path and query on `dash.openmerit.ai`.
+- Redirects use HTTP 308 with `Cache-Control: no-store` to make an operational rollback effective without a long cached redirect.
+- Existing `/demo/api/`, `/demo/internal/`, and `/memo/auth/` requests on `.site` keep their original application handlers and origin checks. This preserves already-open tabs and in-flight container callbacks. New page loads and new sign-ins use `.ai`.
+- Existing dashboard `/api/` requests on `dash.openmerit.site` keep serving the same read-only API so already-open dashboard tabs can continue updating. Upgraded connections pass through intact.
+- Cloudflare serves its managed `robots.txt` directly on each domain before the Worker. Those files remain available on the legacy hosts. Search, agent, and training bot policies are set to Block on both zones; the new domain's robots responses match the originals.
+- HTML and Markdown served on `.ai` use `.ai` links, canonical metadata, social-image URLs, and email addresses. Binary assets and API data pass through unchanged.
+- The four existing inbound aliases (`lazim`, `akhil`, `praveen`, and `invest`) are recreated on `.ai` with the same verified destination mailboxes. Existing `.site` aliases and MX records remain valid, avoiding a mail-forwarding chain or loss of old addresses. Catch-all stays disabled.
+- The OTP sender changes to `memo@openmerit.ai` only after Email Sending has verified SPF, DKIM, DMARC, and bounce-domain DNS. Inbound routing and outbound email sending require separate Cloudflare setup.
+
+There is no OpenMerit Cloudflare Pages project in this account. The pages are served by Workers static assets. The existing `openmerit-site.listenlater-lazim.workers.dev` address remains an application fallback; the public custom domains are the canonical entry points.
+
+## Verification and rollback
+
+Before enabling redirects, check valid public TLS on every `.ai` host; compare live pages and linked assets to the pre-migration capture; test memo delivery, valid OTP, invalid OTP, logout, protected Markdown, and administrator restrictions; check dashboard APIs and its read-only boundary; verify each inbound alias has the same destination and a ready email zone. Do not reset auth limits or storage to make checks pass. A configuration-only or successful send response is not proof of inbox delivery.
+
+Deploy the domain router with `npx --yes wrangler@4.136.3 deploy --config wrangler.domains.jsonc`. Its build hook runs the domain tests and documentation checks. Keep domain ownership in that configuration, rather than adding the same routes back to the application configurations.
+
+Run `node --test demo/test/domain-migration.test.mjs`, `npm run check:docs`, and applicable `npm run verify` checks. Public docs remain generated from Markdown; generated `site/docs/` files are not edited. Homepage product/FAQ claims are unchanged by the domain migration.
+
+Local rollback material and before/after evidence are under `/private/tmp/openmerit-domain-migration/` (private directory). The original main application version is `294f810c-5c46-4353-ab13-67ab0aa89464`; the original terminal version is `111171c5-34bb-4a25-91bc-60f8e96f371e`. The recorded `.site` routes, mail rules, binding metadata, and original deployed modules are preserved there. Restore the previous route ownership and application version together if rollback is needed; keep both domains' mail delivery configured.
+
+## Publication status
+
+The zone activated on 12 October 2026 at 16:45 UTC. Inbound Email Routing is enabled, synchronized, and ready. Email Sending is enabled with configured DNS. A real OTP from `memo@openmerit.ai` reached the owner's inbox with SPF, DKIM, and DMARC passing. A second OTP sent to `lazim@openmerit.ai` reached the same inbox through its `code@lazim.one` destination, verifying the new inbound route.
+
+The main application now uses the verified `.ai` sender while preserving both request origins. The terminal deployment changed only its canonical/social metadata and generated social image; the application JavaScript, CSS, favicon, and flow stylesheet were compared byte-for-byte with production before publishing.
+
+The domain-reference audit covers the README, public guide links, website and memo generators, canonical/Open Graph/Twitter metadata, sharing-image notes, the engineering article's metadata/navigation, hosted dashboard tests, and the demo's provider attribution URLs. GitHub's repository website field is empty. Historical deployment records, compatibility handlers/tests, legacy redirect routes, and the old generated memo snapshot retain their original domains. The two production `HTTP-Referer` constants are changed from `.site` to `.ai` without rebuilding the application or replacing its assets. Both application configurations have empty `routes` arrays; all six public hosts are managed by `wrangler.domains.jsonc`.
+
+All 88 captured legacy URLs retain their original status codes after staging. 83 response bodies are byte-identical; the remaining five are the two intentionally updated dashboard HTML documents and three time-dependent sample API responses. `npm run verify` passed; all seven domain-layer tests and the documentation checks passed.
+
+Valid public HTTPS on all three `.ai` hosts was confirmed at 17:43 UTC. The `.ai` URL comparison retained all 88 original status codes. After matching Cloudflare's crawler policies, 83 bodies match the originals after document-domain substitution; the five exceptions are the two intentionally updated dashboard HTML documents and three time-dependent sample API responses.
+
+A real `.ai` OTP login succeeded in the browser. The protected memo and its 53,283-byte Markdown download were accessible after sign-in, the non-admin reader account was denied the reader list, and sign-out returned to the email gate. Expired/invalid codes and untrusted origins were rejected. Documentation search and its section links, dashboard Activity navigation, and demo initialization worked without browser console errors. Dashboard mutations remain HTTP 405 and the private snapshot route remains 404.
+
+Redirects are enabled. The router owns the old apex/www routes, all three new custom domains, and the old dashboard custom domain. All 88 legacy URLs retain their original final status after cutover and reach the expected host, allowing for the documented API and managed-robots exceptions. HTTP 308 redirects preserve encoded query strings and paths; browser checks also preserved the dashboard fragment. Both email zones remain enabled, synchronized, and ready, with all four new aliases enabled and the catch-all disabled.
+
+Active versions: main application `08a1ad0f-ae83-4179-a4e9-a174ba746b71`; terminal `49abf964-8633-466a-a4c6-29cdc8007f55`; domain router `7e5cbee3-1c26-4cb8-afd6-07b6a092ee31`.
+
+One user-approved live demo request completed with all four comparison cases passing through OpenAI and produced the expected proposed assignment; the session was then ended. OpenRouter candidates returned HTTP 400 from the inference gateway during that run. Their underlying provider error was not exposed, and its cause was not established. This check does not establish that every provider integration is healthy. No additional paid experiment was run, no proposed setup was approved, and no provider credentials, model request bodies, limits, or budgets were changed.

package/docs/site-dynamic-og.md

@@ -1,6 +1,6 @@
 # Page sharing images
 
-Separate page images are disabled for now at the user's request. The homepage and all documentation pages use `https://openmerit.site/assets/openmerit-og-v1.png` for Open Graph and Twitter cards. No entries in `scripts/docs.config.mjs` currently enable `socialImage`.
+Separate page images are disabled for now at the user's request. The homepage and all documentation page sources use `https://openmerit.ai/assets/openmerit-og-v1.png` for Open Graph and Twitter cards. See the [domain migration status](site-domain-migration.md) for activation and cutover verification. No entries in `scripts/docs.config.mjs` currently enable `socialImage`.
 
 The optional template and workshop artwork remain available for later use. Normal docs builds do not render a separate page card. The previously published `/docs/og.png` path serves a copy of the default image so cached sharing metadata still resolves.
 
@@ -16,7 +16,7 @@ Enabled cards are generated during the build and served as PNGs. They are not re
 
 ## URLs and future pages
 
-When enabled for the overview, a custom image is written to `site/docs/og.png`, alongside the generated page, and assigned through `https://openmerit.site/docs/og.png?v=<content-hash>`. The hash comes from the rendered PNG, so changing the title, workshop artwork, font, or template changes the URL when it changes the pixels. Rebuilding the same card produces the same URL. Description or package-version updates do not invalidate an unchanged custom image; those details are not printed on the card.
+When enabled for the overview, a custom image is written to `site/docs/og.png`, alongside the generated page, and assigned through `https://openmerit.ai/docs/og.png?v=<content-hash>`. The hash comes from the rendered PNG, so changing the title, workshop artwork, font, or template changes the URL when it changes the pixels. Rebuilding the same card produces the same URL. Description or package-version updates do not invalidate an unchanged custom image; those details are not printed on the card.
 
 The physical PNG path stays stable. Previously shared image URLs with an older query parameter still resolve after a deployment instead of pointing to a deleted filename. Social platforms control their own preview caches and may retain a previously fetched card.
 

package/docs/site-faq-maintenance.md

@@ -1,6 +1,16 @@
 # Website FAQ maintenance
 
-The public FAQ lives in `site/index.html`. Its answers describe the published package, including known limitations, rather than planned capabilities or unreleased fixes.
+The public FAQ lives in `site/index.html`. Its answers describe implemented behavior verified against main and the published package, including known limitations. Appearance differences between npm 0.1.6 and the hosted/source interface are identified separately in the terminal guide.
+
+## Current factual review — 14 October 2026
+
+Reviewed main against the published `openmerit@0.1.6` artifact and the hosted dashboard/demo. Stable installation includes `openmerit dash`; Pi is optional for the separate comparison workflow. The homepage now introduces the standalone terminal and links the demo guide, which distinguishes fictional hosted samples from the recorded player retained in main.
+
+Updated background scheduling, durable pause, challenger-budget accounting, and terminal data-handling claims. The macOS LaunchAgent requires confirmed persistent execution and infrastructure permission, a logged-in user, and headless Pi authentication. Pause gates automatic work but does not cancel active intents or disable explicit commands. Budget admission and result validation use reported challenger costs; they are not provider billing controls. The terminal indexes supported source/configuration declarations, reads existing application evidence, and retains selected metadata in memory. It does not invoke the coordinator, make inference calls, or mutate model configuration.
+
+Removed obsolete 0.1.5 comparisons and preview release chronology from current public guides. Retained uncertainty, incomplete coverage, supervised-validation limits, and npm-versus-hosted appearance disclosure. The following dated entries are historical records, not the current release contract. The docs and website were subsequently published on 14 October; npm was not changed. See the [publication record](site-publication-2026-10-14.md). Direct root-configuration deployments still require production-source reconciliation.
+
+## Historical reviews
 
 Last factual review: 2026-09-23, against npm `openmerit@0.1.5`, the Pi 0.87 adapter, and the current source. The FAQ contains 13 questions. The earlier audit reproduced a task-triggered assessment while `/openmerit status` reported paused and confirmed the same dispatch path in the published package.
 
@@ -19,11 +29,11 @@ The experimental `npm run demo` sandbox is a repository-local live-provider demo
 | `faq-evidence` | Required samples; unresolved candidates; evidence trust | Core feasibility and frontier verification, `docs/metrics-and-evidence.md`, `docs/security.md` |
 | `faq-approval` | Opt-in automation; zero-capable graduation threshold; post-swap evaluation | Core `nextImprovementAction`, `packages/protocol/src/schemas.ts` (`SupervisedGraduationPolicySchema`), Pi `approve` command |
 | `faq-regressions` | Post-swap regression handling; conditional rollback | Core `interpretIntentResult` and `nextImprovementAction`, `docs/lifecycle.md` |
-| `faq-background` | Active-session signals; no built-in persistent scheduler | Pi `PI_HARNESS_DESCRIPTOR`, core `buildAutomationPlan`, `docs/automation.md` |
+| `faq-background` | CLI lifetime; authorized macOS LaunchAgent; other-platform gaps; product-validation limits | Pi `PI_HARNESS_DESCRIPTOR`, core `buildAutomationPlan`, `docs/automation.md` |
 | `faq-pause` | Which automatic dispatches stop; restart behavior; active work | Pi `reportAutomationSignal`, `createInitialUiState`, completion handler and `pause` command; `docs/operations.md` |
 | `faq-data` | Project files; Pi session entries; harness/provider data flows | `packages/core/src/store.ts`, Pi `appendEntry` and `privateIntentMessage`, `docs/security.md` |
 | `faq-cost` | License; npm availability; provider and infrastructure costs | `LICENSE`, published npm metadata, harness execution path |
-| `faq-budget` | Budget passed to harness; absence or presence of metering/cutoffs | Core `createOpenMeritIntent`, budget consumers across `packages/` |
+| `faq-budget` | Reported challenger ledger, admission/result checks, separate costs, no independent provider-billing cutoff | Core `createOpenMeritIntent`, budget consumers across `packages/` |
 | `faq-readiness` | Implemented, tested, and product-validated behavior | `docs/testing.md`, `docs/roadmap.md`, actual product-trial evidence |
 
 ## Review during releases and website updates
@@ -183,8 +193,113 @@ Reviewed startup, background collection, data handling, coverage and readiness c
 Prepared `0.1.6-preview.5` for the existing npm preview channel. The source build passed all 281 verification tests. A separate 5,001-file synthetic repository on the four-core, 4 GiB VM exposed 25,001 references: URL ready in 43 ms, first declarations at about 1 second, full index at 4.1 seconds. An edit/deletion pass reused 4,998 files, read about 9 KiB, and completed in 1.27 seconds. These are fixture measurements, not a universal performance guarantee. The private VM source build preserved all 246 real request records and all 128 application files through passive refresh. Registry publication and installation verification are pending. The guide identifies behavior by minimum version; stable `latest`, homepage FAQ claims, and site deployments are unchanged.
 
 
-## npm default-channel release preparation — 11 October 2026
+## Phased repository indexing — published preview.5, 10 October 2026
+
+Published and verified `0.1.6-preview.5`, superseding the unreleased/preparation status above. The npm integrity matches the tested archive and `preview` points to this version; stable `latest` remains `0.1.5`. A direct `npm install -g openmerit@preview` on the VM succeeded, and the persistent dashboard now runs that global registry package instead of the temporary source-build override. All 246 real records and 128 application files remain unchanged across passive refresh. Counts-only diagnostics, full JSON output, package exports, and all 61 packaged code/asset/metadata file hashes passed; served browser assets match the release. No inference calls were made. The existing activity/runtime limits and static-declaration evidence boundaries remain documented. Homepage FAQ wording and site deployments are unchanged.
+
+
+## Hosted sample synchronization — 10 October 2026
+
+Deployed the fictional sample at `dash.openmerit.site` with the preview.5 browser assets and current sample generator. The public data disclosure and sample-only API boundary remain intact; repository scanning, local runtime collection, and phased indexing do not run on visitors' environments. Historical range controls describe the available sample records, not a complete project-lifetime archive. The main-site FAQ and deployment remain unchanged. Live assets, sample counts, read-only API behavior, and desktop/mobile browser checks passed; see [the sample deployment record](site-terminal-preview.md).
+
+## Hosted enterprise comparison — 10 October 2026
+
+Reviewed evidence, pricing and readiness claims. The hosted comparison uses fictional workload volumes and published token rates, clearly labels model assignments as illustrative, and makes no measured quality or latency claim. Unknown costs remain unknown. No changes to local collection, consent, routing, evaluations, billing or the published npm preview are implied. The main homepage FAQ requires no change.
+
+
+## Insurance comparison evidence and preferences — 10 October 2026
+
+Reviewed the hosted demo's quality, price, privacy and model-selection claims. Replacements now require the selected public benchmark screen and a cost or paired-latency improvement. Publisher point estimates are distinct from application evaluations; missing evidence retains the baseline. Preference conflicts remain visible, including unresolved open-weight baselines under the closed-only option. ZDR is endpoint/account-specific and developer origin is separate from residency. Fictional insurance names and fixed token volumes remain explicit. No local discovery, runtime routing, evaluation-engine, npm or homepage FAQ behavior changes. Deployment verification is recorded separately.
+
+
+## Expanded comparison selection — 10 October 2026
+
+Reviewed the hosted preference behavior against the public guide. The dated catalog searches 25 offers across six configured services and distinguishes model identity from endpoint pricing and ZDR. A hard no-open-weights conflict blocks the complete After plan and its projected cost. Soft biases can produce identical selections; the UI exposes matches and equality with Default instead of implying arbitrary changes. Benchmarks remain public screening signals, not measured application-quality or endpoint-latency evidence. The main homepage FAQ and published npm behavior require no changes.
+
+
+### Incomplete comparison plans — 10 October 2026
+
+Reviewed hosted comparison claims after replacing the whole-plan block with a visible partial plan. The closed-weight requirement remains enforced per assignment: unresolved workflows have no After assignment or usage. Qualifying workloads remain inspectable, their subset coverage is disclosed, and complete-plan savings remain unavailable. No local collection, real routing, npm or homepage FAQ claims change.
+
+
+## Hosted preference comparison expansion — source, 10 October 2026
+
+Reviewed homepage FAQ claims against the expanded fictional comparison. The new application workloads, benchmark cohorts, fixed token profiles and preference-dependent costs affect only the hosted demonstration. They do not establish live model-routing performance, production discovery coverage or a new npm release. Existing public FAQ claims remain unchanged; detailed assumptions and limits are maintained in `inference-terminal.md`.
+
+
+## Preference overrides — source, 10 October 2026
+
+Reviewed comparison, evidence, approval and regression claims. This change is confined to the fictional hosted comparison: a selected preference may override benchmark and efficiency criteria, with explicit exceptions and truthful prices. It never weakens the live evaluation engine, routing approvals, endpoint compatibility or source collection. No real inference or insurance decision is made. The main homepage FAQ and published npm release remain unchanged. Hosted publication and verification are recorded separately.
+
+
+## Comparison visual hierarchy — source, 10 October 2026
+
+Reviewed the hosted comparison's presentation. The leading dark panel makes stage controls, fixed token costs and their modeled difference more prominent while keeping override disclosures and evidence visible. Selection and pricing rules are unchanged. No homepage FAQ, npm or live routing claim changes.
+
+
+## Primary domain migration — preparation, 12 October 2026
+
+The `.ai` migration changes hostnames and mail configuration, not product behavior or readiness. Existing homepage FAQ claims remain unchanged. The protected memo, OTP limits, reader data, and interactive demo must be preserved from the deployed Worker because this checkout lacks parts of the current production source. See [migration operations and verification](site-domain-migration.md) for cutover status; DNS preparation alone does not establish successful publication or email delivery.
+
+## Automatic light and dark appearance — unreleased source, 14 October 2026
+
+Reviewed homepage FAQ claims against the appearance-only change. Device-driven colors affect website reading surfaces, demos, and the Inference Terminal, including charts and overlays. They add no saved theme preference, inference calls, collection, routing, permissions, or billing behavior. No FAQ wording change is required. The terminal guide separates the unreleased source appearance from published preview.5. Website/npm publication is not implied by local builds; the main-app source divergence and integration boundary are recorded in [theme maintenance](site-themes.md).
+
+## Scout — unreleased branch preview, 14 October 2026
+
+Reviewed evidence, comparisons, data, background checks, cost, and readiness claims. Scout adds a separate prompt-only shortlist API and `/scout/` page; it does not change Pi approvals, evaluations, automatic swaps, terminal collection, or the published npm package. Its preview guide explains fixed ranking defaults, source/configuration differences, old visual evidence, missing speed, HTTP-only vision source transport, token-price assumptions, in-memory prompt handling, and hourly refresh lifetime. The homepage gains a navigation link; existing FAQ answers continue describing the terminal and Pi workflow and need no behavioral rewrite. Local checks do not establish a hosted deployment or state-of-the-art recommendation quality.
+
+## Scout launch preparation — 14 October 2026
+
+Reviewed freshness, real-data, privacy, price, speed and recommendation claims against the five-source importer and prompt-only API/MCP tool. The guide now documents independent source recovery, archived measurements, OmniDocBench's actual table version, uncertainty adjustment, and the limits of phrase matching. The page starts with a real empty input. Scout is a separate beta and does not establish SOTA task accuracy. No Pi/npm approval, budget or routing behavior changes. Hosted publication is verified separately.
+
+## Scout publication — 14 October 2026
+
+Scout's page, JSON API and MCP tool are now hosted, with an hourly Worker trigger and independently refreshed real public sources. The homepage navigation and generated documentation were published while preserving the deployed main application. Existing FAQ answers still describe the terminal/Pi workflow; no edits to those behavior claims were required. Publication and verification boundaries are recorded in [the Scout launch record](site-scout.md).
+
+## Scout comparison table — 14 October 2026
+
+Reviewed evidence, comparison, data handling and readiness claims for the semantic results table and bundled provider favicons. This changes presentation and evidence disclosure controls only; ranking, API/MCP responses and prompt handling remain unchanged. Icons use a curated local registry, with no remote favicon requests from the browser. No homepage FAQ wording change is required. Publication and browser verification are recorded separately in [the Scout launch record](site-scout.md).
+
+
+## Scout Decisions integration — release preparation, 14 October 2026
+
+Reviewed data handling, inference cost, evidence, scheduling and readiness claims. Scout now makes one server-side OpenAI Decisions call per prompt; its page and guide disclose this before submission. BFCL adds explicit tool-calling and external-memory evidence, with strict eligibility and source limitations. Fixed cost/quality/speed weights remain unchanged. The homepage FAQ continues to describe terminal/Pi behavior, so no FAQ copy change is required. This does not change terminal approvals, provider budgets, the npm package or local routing. Live publication is recorded separately in the Scout launch record.
+
+
+## Scout ranking revision — 14 October 2026
+
+Checked homepage FAQ claims against the proposed ranking revision. FAQ answers still describe the terminal/Pi workflow; Scout does not change its budgets, approvals or routing contracts. The Scout guide and table now disclose same-benchmark pairwise ordering, prompt-shaped reference cost, first-answer completion timing, tradeoff defaults, and incomplete comparison coverage. Reference estimates must not be described as measured task accuracy, actual endpoint latency or exact per-task charges. No general SOTA claim is established by the small task evaluations. Deployment and measured evaluation outcomes are recorded separately in the Scout publication notes.
+
+
+## Scout measured-task ranking — 14 October 2026
+
+Reviewed evidence, data, costs, scheduling and readiness claims for the Scout change. The separate Scout service uses calibration-only aggregates for narrow matching tasks, and public benchmark comparisons elsewhere. Held-out results are not loaded into ranking. Evaluation requires an explicit offline run; the existing hourly job still only refreshes six public feeds. No user task execution, saved prompt history, extra runtime inference, or database is introduced. Small samples and the selected candidate pool do not establish SOTA or a perfect ordered top five. Homepage FAQ claims concern the terminal/package and need no changes. Publication and test outcomes are recorded in `site-scout.md`.
+
+
+## Scout interface refinement — 14 October 2026
+
+Checked comparison, evidence and data-handling claims for the terminal-style Scout interface. Ranking and API/MCP contracts are unchanged. The page retains its OpenAI prompt-processing notice, measurement scope and limitations. Bundled provider marks replace boxed favicons; missing assets use text-only names. No homepage FAQ wording change is needed.
+
+## Scout compact controls — 15 October 2026
+
+Reviewed index coverage, evidence and data-handling claims. The header counts indexed models, distinct model creators, benchmark series and source feeds; it does not equate series with independent publishers or creators with hosting routes. Row disclosures retain benchmark and measured evidence, while sample/workload context moves into the existing limitations disclosure. The prompt-processing sentence is removed from the form at the user's request; the public Scout guide retains the OpenAI data-flow and retention description. Ranking, persistence and terminal/Pi behavior are unchanged. No homepage FAQ copy change is needed; publication is recorded separately in the Scout notes.
+
+## Scout execution evidence — 15 October 2026
+
+Reviewed evidence, comparisons, cost, latency, memory and data claims. The ranking extends the existing offline calibration path to specified code, dependent tool actions and external memory, with explicit execution/retention matching and full-episode cost/time. It adds no runtime provider evaluation, extra inference call, model-specific bonus or persistence of user prompts. The previous broad audit becomes development data; new held-out cases remain excluded. Failed candidate profiles are withheld, and missing action-pool coverage is filled through separate calibration before another fresh check. Selected pools and small samples cannot prove a universally correct ordered five. Homepage FAQ answers still describe terminal/Pi behavior and need no copy changes. Publication and fresh validation are recorded in the Scout notes.
+
+
+## Agent evaluation loop — unreleased source, 15 October 2026
+
+Reviewed harness support, evaluations, costs, budgets, data and scheduling. The new standalone eval commands are separate from terminal collection and Pi application evaluation. Source docs mark them unreleased; published npm 0.1.6 and homepage FAQ claims are unchanged. Project instructions are opt-in through init, not install hooks. Watch is foreground-only, cumulative reservations are admission controls rather than billing caps, unknown usage/cost stays unknown, and Scout eligibility filtering happens before ranking. No performance guarantee or automatic production model swap is introduced.
+
+
+## Scout model detail cleanup — 15 October 2026
+
+Reviewed evidence and comparison claims after removing the prose summary from every expanded model row. Measurement scope remains in Assumptions & limitations and source-linked evidence remains in the details. Ranking and API/MCP metadata are unchanged; homepage FAQ wording requires no change.
+
 
-Prepared `0.1.6` using the unchanged runtime code from npm `0.1.6-preview.5`. The packaged README, terminal install guide, command entry, architecture/operations references, and terminal security boundaries now describe the default npm installation. Registry publication remains pending release verification and authentication.
+## Agent evaluation npm preview — 15 October 2026
 
-Reviewed homepage evidence, data, background, cost, and readiness claims. The terminal remains passive, requires recorded evidence for usage, does not call models or perform routing/evaluations, and stops when the command exits. Indexing is explicitly local and syntax-limited. Its availability in the default npm package does not establish the complete OpenMerit product vision or measured optimization results. Pi coordinator behavior is unchanged from the preview; existing version-specific `0.1.5` caveats are historical. This is an npm-only release: repository branches, the website, and its separately deployed documentation are not changed or deployed. The npm README points to the bundled terminal guide for this version's behavior.
+Prepared the `0.1.7-preview.1` npm preview with explicit installation and setup instructions. The stable `latest` tag remains `0.1.6`. Reviewed homepage readiness, evaluation, budget and data claims: they describe stable terminal/Pi behavior and require no copy changes. The preview retains explicit initialization, connection scope, local execution and budget limitations; no install-time automation is claimed.

package/docs/site-hero-resolution.md

@@ -4,6 +4,8 @@ The first generated 2 × 2 hero sheet was 2172 × 724 overall, leaving each pose
 
 ## Final assets
 
+The table records the original full-resolution opaque frames. As of the 14 October 2026 source update, the homepage uses matching `hero-frame-{0..3}-transparent-v3.webp` cutouts at the same 2172 × 724 resolution. See [the transparency update](site-illustration-transparency.md); it was published on 14 October 2026.
+
 | Pose | Workspace asset | Source |
 | --- | --- | --- |
 | Rest | `site/assets/motion/hero-frame-0-v2.webp` | Original full-resolution PNG, `exec-c120bc1a-6cea-4824-a27a-81b382be4063.png`. |

package/docs/site-illustration-sequences.md

@@ -1,9 +1,11 @@
 # Illustrated frame sequences
 
-Generated with the built-in image generation tool on 2026-09-23. These replace the SVG displacement animation. Each atlas contains distinct poses; the player only copies whole cells to a canvas. There are no mesh deformations, optical-flow frames, morphs, or crossfades.
+Generated with the built-in image generation tool on 2026-09-23. These replace the SVG displacement animation. Each atlas contains distinct poses. Supporting scenes copy whole cells to a canvas; the current hero source keeps a fixed stage and registers only the moving maker above the bench. There are no mesh deformations, optical-flow frames, morphs, or crossfades.
 
 ## Assets and playback
 
+Published update, 14 October 2026: the active homepage assets now use transparent backgrounds. The four hero files are `hero-frame-{0..3}-transparent-v3.webp`; the supporting atlases and posters are `{setup,questions,rest}-sequence-transparent-v2.webp` and `{setup,questions,rest}-poster-transparent-v2.webp`. Their dimensions, poses, frame order, and timing remain unchanged. The hero renderer corrects camera drift in the generated sources by retaining the first-frame workshop and registering only the moving maker. See [transparent asset provenance, packaging, and playback](site-illustration-transparency.md). The table and generation notes below document the original opaque versions retained as references; their byte totals do not describe the transparent exports.
+
 | Scene | Atlas | Grid | Frame size | Action |
 | --- | --- | --- | --- | --- |
 | Hero | `site/assets/motion/hero-frame-{0..3}-v2.webp` | Four individual images | 2172 × 724 | Seated maker raises and examines a hand plane. |

package/docs/site-illustration-transparency.md

@@ -0,0 +1,80 @@
+# Transparent landing-page illustrations
+
+Published update, 14 October 2026; see the [publication record](site-publication-2026-10-14.md). The homepage's hero, setup toolbox, FAQ makers, and footer dog now use true alpha transparency. The paper panels and multiply/brightness treatments have been removed. The same artwork blends with both device-driven themes and the setup section's tinted surface.
+
+## Assets and provenance
+
+Background removal used the built-in image generation tool, one edit per original frame or atlas, with `transparent_background: true`. The seven edit targets were inspected first. All outputs retained their original 2172 × 724 dimensions and pose sequence. Matching image dimensions did not guarantee matching camera scale: the later hero poses contain scale and position drift. Playback now corrects this as described below. The original opaque assets remain available as references.
+
+All production files live in `site/assets/motion/`. Generated PNG masters are retained under `/Users/lazim/.codex/generated_images/01a139ac-2d03-7392-8dc0-46b579f1b0a2/`.
+
+| Original edit target | Transparent workspace asset | Generated PNG master |
+| --- | --- | --- |
+| `hero-frame-0-v2.webp` | `hero-frame-0-transparent-v3.webp` | `exec-1b433f01-7b97-4fbd-a783-bc492410a513.png` |
+| `hero-frame-1-v2.webp` | `hero-frame-1-transparent-v3.webp` | `exec-37831b7f-2824-4b2b-b596-92776f1a9a2f.png` |
+| `hero-frame-2-v2.webp` | `hero-frame-2-transparent-v3.webp` | `exec-ee801aab-4889-4e42-a28c-7cdfe768193b.png` |
+| `hero-frame-3-v2.webp` | `hero-frame-3-transparent-v3.webp` | `exec-3e035cd4-1db1-48a1-810c-4b614a1dc2cb.png` |
+| `setup-sequence-v1.webp` | `setup-sequence-transparent-v2.webp` | `exec-883bde34-d6b0-493f-948b-6fb1c7a46e1d.png` |
+| `questions-sequence-v1.webp` | `questions-sequence-transparent-v2.webp` | `exec-e4f8c1b1-dd3b-4300-bcf2-6ab0ce1a5ca1.png` |
+| `rest-sequence-v1.webp` | `rest-sequence-transparent-v2.webp` | `exec-7e61da58-8037-4c73-b093-74baed7c3ab1.png` |
+
+The three supporting posters are `setup-poster-transparent-v2.webp`, `questions-poster-transparent-v2.webp`, and `rest-poster-transparent-v2.webp`. Each is exactly the first 543 × 362 cell of its decoded atlas. The hero poster is its first full-size frame.
+
+Packaging uses `cwebp -q 92 -alpha_q 100 -m 6` without resizing. Supporting posters are extracted from decoded WebP atlases and encoded losslessly, preserving exact displayed first-frame pixels. No alpha edits, warping, generated intermediate poses, or frame registration changes are performed during packaging.
+
+## Playback
+
+The canvas clears before each pose. Once its first complete frame is ready, `.has-motion-frame` makes the poster transparent while retaining its dimensions and accessible image description. This prevents the old pose from showing through transparent regions in subsequent frames.
+
+Pause holds the current pose. Reduced motion restores the static poster and hides the canvas; print does the same. Unloaded or failed animation assets and no-JavaScript visits retain the transparent poster. Timing, lazy loading, offscreen stopping, hidden-tab stopping, and pause preference persistence are unchanged.
+
+### Stable hero stage
+
+The first hero frame supplies the fixed workshop in every pose. Only the seated maker above the bench is replaced, inside the polygon `[[795,235],[1060,235],[1060,435],[1010,463],[825,463],[795,435]]`. The other makers, benches, tools outside this region, plant, stool, legs, and dog remain pixel-identical throughout the loop.
+
+Each moving source pose uses a fixed uniform registration measured against the original stool and bench. The `(scale, x, y)` values are `(1, 0, 0)`, `(1.002, -9, -2)`, `(.956, 43, 46)`, and `(.962, 35, 35)`. These compensate for the generated camera changes; they are not animated zooms, morphs, or interpolation between poses. The clip follows the space above the bench to preserve the stationary tabletop. The calibrated sources must be exactly 2172 × 724; an incompatible source leaves the poster visible.
+
+The three supporting atlases retain whole-cell playback. Their stationary furniture does not show the progressive hero-scale drift; inspection and registration checks found only small existing pose-to-pose texture and placement differences.
+
+## Exact edit prompts
+
+### Hero (same prompt for each of the four original frames)
+
+```text
+Use case: background-extraction.
+Asset type: production website illustration, original full-width hero animation frame.
+Input image 1 is the EDIT TARGET, not a style reference.
+Primary request: remove only the solid white/cream paper background, returning the existing artwork on a genuinely transparent alpha background. This is precise background removal, not a new illustration.
+Preserve the entire miniature workshop exactly: all six people, faces, poses, clothing, tools, benches, table legs, the small plant and the sleeping dog. Preserve all pixel positions, dimensions, scale, framing, natural colors, lighting, fine texture and focus. Keep this single wide 3:1 canvas at 2172 x 724 pixels, including its original transparent empty margins. Do not rearrange, redraw, crop, enlarge, shrink or change the artwork.
+Remove the white background also from every open gap between legs, under tables and around the plant, tools and figures. Preserve white/cream fabric, white hair, dog fur and highlights belonging to real objects as opaque details. Preserve only subtle localized contact shadows as translucent neutral shadows, with no white floor or broad paper patch. Clean antialiased edges with no pale halo, white fringe or checkerboard; it must sit naturally on both warm off-white and charcoal website backgrounds.
+Output just the original single complete illustration, unchanged except its background is transparent.
+```
+
+### Supporting atlases (common prompt)
+
+```text
+Use case: background-extraction.
+Asset type: production website animation spritesheet.
+Input image 1 is the EDIT TARGET, not a style reference.
+Primary request: remove only the solid white/cream background from the existing artwork and output actual transparent alpha.
+Keep this entire canvas exactly 2172 x 724 pixels. Preserve the existing FOUR COLUMN by TWO ROW grid of EIGHT distinct poses, with cells of 543 x 362 pixels. Every object in every cell must remain at its original coordinates, scale, framing, orientation and pose. Do not combine cells, crop, scale, rearrange, redraw, add gutters or change anything in the artwork.
+Remove all empty white/cream paper around the subjects, including open interior gaps. Preserve light-colored fabric, fur, hair, highlights and other light-colored real subject details as opaque. Keep only subtle localized contact shadows as translucent neutral shadows. No white floor, broad paper patch, pale halo, white fringe, colored edge artifacts, or checkerboard. Clean antialiased edges suitable for both warm off-white and dark charcoal website backgrounds.
+```
+
+Each atlas appends its scene-specific constraint:
+
+- **setup:** Preserve the wooden toolbox, contents, brass calipers, folded linen and the exact successive lid-opening angles in all eight cells.
+- **questions:** Preserve both makers, their faces, clothing, table, stool, notebook, feet and the exact successive pointing hand poses in all eight cells.
+- **rest:** Preserve the spaniel, fur, toolbox, linen and exact successive poses of the dog raising its head in all eight cells.
+
+## Verification
+
+Chromium browser checks passed in both device themes at 1440px and 390px. All four scenes have transparent containers, normal compositing, no image filters, matching intrinsic dimensions, and no horizontal page overflow. Actual timed frame changes were observed for every scene; the underlying poster is hidden during playback. All 28 poses retain substantial transparent regions, and the supporting posters match the decoded first atlas cells pixel for pixel.
+
+The animation regression check now compares rendered RGBA pixels across the complete forward/reverse hero sequence. No pixel changes outside the maker's motion bounds are permitted, and each raised pose must still contain distinct moving pixels. The four corrected poses were also inspected together at their native scale. The previous dimensions-and-motion checks alone were insufficient to catch the camera drift.
+
+Pause and its reload persistence, live theme changes without shifting the artwork, reduced-motion changes, print posters, failed-animation fallback, and no-JavaScript mobile rendering passed. No application runtime errors occurred. Desktop and mobile screenshots were visually reviewed. `npm run check:docs`, JavaScript syntax validation, and `git diff --check` passed. This is browser emulation, not a physical-device test.
+
+## Publication
+
+Integrate these assets, `site/index.html`, `site/styles.css`, and `site/illustrations.js` with the preserved production application described in [the theme notes](site-themes.md). A local preview or successful check does not publish the change. Social sharing artwork is separate from the four on-page illustration scenes and remains unchanged.

package/docs/site-memo.md

@@ -1,5 +1,7 @@
 # Website memo
 
+Domain operations: see the [primary domain migration](site-domain-migration.md) for current routing, email, auth, and deployment constraints. Historical publication records below retain their original domains.
+
 The standalone `/memo/` page renders [Lazim's supplied memo](memo.md), “Optimum Inference For All.” The Markdown is the single maintained source; its wording and reading links are preserved from the supplied text. It describes the company's direction, including proposed capabilities and business model, rather than the released package contract. The homepage FAQ continues to describe released behavior.
 
 ## Editing and building
@@ -37,3 +39,7 @@ The header addition passed all 11 documentation checks. Browser checks at 320, 3
 ## Production publication
 
 Published on September 28, 2026 as Worker `6b9dfbd1-d9a0-4f13-9120-4e754774998a`. The memo HTML, exact Markdown download, stylesheet, and abstract header artwork on both `openmerit.site` and `www.openmerit.site` match the maintained local build byte for byte. The homepage navigation is also published and matched. Repository verification and all 11 documentation checks passed.
+
+## Device appearance — published 14 October 2026
+
+Memo prose, tables, SVG diagrams, and the recovered protected-memo access components now use the shared device-driven light/dark palette. The email gate, code-entry/error states, reader list, and message pages use the same colors. Print remains light. No authentication logic or protected content was changed. See [theme maintenance](site-themes.md), including the production-source mismatch and presentation-only verification limits.

package/docs/site-og-image.md

@@ -4,7 +4,7 @@ This is the shared default image for the homepage and all documentation pages. [
 
 Final asset: `site/assets/openmerit-og-v1.png` (1200 × 630 pixels, PNG).
 
-Public URL: https://openmerit.site/assets/openmerit-og-v1.png
+Primary-domain URL: https://openmerit.ai/assets/openmerit-og-v1.png. See the [domain migration status](site-domain-migration.md) for activation and cutover verification.
 
 Created with the built-in imagegen tool using the existing diverse miniature workshop as a style reference. The only visible text is “Good models prove themselves in the work.” The card features three diverse makers comparing and measuring tools at a wooden bench, plus the workshop spaniel.
 

package/docs/site-publication-2026-10-14.md

@@ -0,0 +1,29 @@
+# Website and dashboard publication — 14 October 2026
+
+The current documentation, automatic device appearance, transparent landing-page illustrations, and stable hero animation are published to `openmerit.ai` and `dash.openmerit.ai`. The dashboard comparison remains at `https://dash.openmerit.ai/demo`. No npm release was made; npm 0.1.6 retains its previous interface appearance.
+
+## Deployed versions
+
+- Main website: `62ac686b-2895-4263-8e55-053119d2eb27`.
+- Hosted dashboard and comparison: `ee29f3a2-e117-4098-b582-88018b621dfa`.
+- Domain router: unchanged from `7e5cbee3-1c26-4cb8-afd6-07b6a092ee31`.
+
+The dashboard used `npm run deploy:dash-preview`, including its build, documentation checks, syntax checks, and 193 terminal tests. The website used Cloudflare's version and asset-upload APIs against the preserved production application, as required by the [domain migration constraints](site-domain-migration.md). The root Wrangler configuration was not deployed.
+
+## Preserved application and updated assets
+
+Before publication, the active website version was `08a1ad0f-ae83-4179-a4e9-a174ba746b71`; the dashboard version was `49abf964-8633-466a-a4c6-29cdc8007f55`. Their modules and binding metadata were backed up. The website asset staging retained 81 existing public files, then overlaid the reviewed homepage, shared styles, artwork, engineering presentation, and generated documentation. Cloudflare's edge-injected analytics script was removed from captured HTML before upload; the existing zone continues adding it once.
+
+The protected memo was never uploaded as a public static asset. Its deployed application module was preserved, with only two appearance-metadata replacements in its page templates. Memo prose, diagrams, authentication handlers, reader data, secrets, origins, email configuration, Durable Objects, containers, and storage bindings remain unchanged. Binding and runtime metadata were compared before activation.
+
+The interactive demo retains its deployed `guided-20261002-v9` application and JavaScript. Only its stylesheet and appearance metadata changed. A legacy application rule that returned 404 for `/docs/demo*` was narrowed to demo application paths so the maintained demo guides can be served. No inference session was started and no provider calls were made for publication.
+
+The website now generates 24 guides from Markdown. `docs/interactive-demo.md` was recovered from the preserved production-source branch and added to `scripts/docs.config.mjs`, because the live interactive demo links to it. Its introduction explicitly distinguishes the hosted experiment from main's historical recorded player and the dashboard's fictional comparison. Generated files in `site/docs/` remain build output.
+
+## Verification and rollback material
+
+The pre-publication full verification passed all 311 tests. Final documentation checks passed all 12 tests after adding the interactive guide and updating publication distinctions. Live verification compared all 113 staged website assets with their served output, allowing only the existing domain substitution and one Cloudflare analytics injection in HTML. The dashboard HTML, demo HTML, JavaScript, and both chart styles/bundles match the built files byte for byte.
+
+Unauthenticated memo pages, Markdown, reader lists, and CSV downloads still return the email gate with private caching. Foreign-origin authentication requests return 403. The dashboard's private snapshot returns 404 and mutation requests return 405. Legacy and www redirects preserve paths and queries. Browser checks confirmed the live terminal and interactive guides, documentation search, and the dashboard comparison. Email delivery and a new paid demo run were not repeated; their handlers and configuration were preserved.
+
+Private operational backups, upload manifests, exact application patches, deployment responses, and verification results are under `/private/tmp/openmerit-publication-20261014/`. They are not committed. The original versions above remain the rollback references. Do not use an older root source build as rollback: the source divergence still exists. Future main-site deployments must preserve or reconcile the newer memo and interactive-demo application first.

package/docs/site-scout-decisions-experiment.md

@@ -0,0 +1,87 @@
+# Scout Decisions experiment — 14 October 2026
+
+Historical status: this initial experiment was local only and did not change production. The subsequent integration below supersedes its implementation status; see the Scout launch record for verified publication.
+
+## Question and method
+
+Does interpreting the user's task with OpenAI Decisions improve capability selection before Scout's existing evidence-based ranking?
+
+The experiment uses `gpt-6-luna` through `POST /v1/decisions`, one call containing 14 independent choice questions per prompt. It sends only the synthetic prompts in `scout/experiments/decisions-cases.mjs`, not candidate model names, rankings, credentials, or production traffic. This is an opt-in developer command, not part of normal verification:
+
+```sh
+node scout/experiments/run-decisions.mjs /absolute/path/results.json
+```
+
+`OPENAI_API_KEY` must be available in the environment. Running this command incurs API usage and saves prompts, responses, usage and derived rankings to the specified local file. It does not save the key. The Worker does not import these experimental modules.
+
+Twenty prompts and 65 selected boolean expectations were written before the calls. Four additional requests repeat the invoice wording pair, giving 24 requests total. The cases target known weaknesses and are not a representative or independently labeled evaluation set. Expectations check selected dimensions, not every possible classifier output. Memory and tool-interface judgments are assessed separately because the baseline does not expose these fields.
+
+Both interpreters use the identical bundled snapshot from `2026-10-14T15:33:40.447Z`: 211 models and 137 benchmark series. Prices, evidence, filtering, and the 80% quality / 13% price / 7% throughput formula are held fixed. Decisions changes capability selection and weights: absent/uncertain = 0, useful = 1, required = 3, with Scout's existing document multiplier of two. This experiment does not yet interpret price/speed preferences or enforce new tool, context-length or memory constraints.
+
+## Observations
+
+| Measurement | Keywords | Decisions |
+| --- | --- | --- |
+| Specified capability checks passed | 49/65 | 65/65 |
+| Cases passing every specified check | 9/20 | 20/20 |
+| Invoice rankings across six requests / two wording variants | 2 distinct rankings | 1 ranking |
+| Explicit memory-scope judgments | Not represented | 20/20 matched expectations |
+| Tool-interface judgments | Not represented | 20/20 matched expectations |
+
+The perfect result applies only to the selected checks. Manual review found additional incorrect outputs below; it is not a claim of perfect classification accuracy. Sixteen of twenty top-five lists changed. A different list does not establish a better list without testing the candidate models on actual work.
+
+The original invoice paragraph and its `tool` → `application` variant both produced documents = 6, structured = 3, vision = 3, with no agent requirement. All six requests returned:
+
+1. GPT-5 Mini
+2. Gemini 2.5 Pro
+3. Gemini 3 Flash Preview
+4. GPT-4.1 Mini
+5. GPT-5
+
+The original keyword result had Gemini 3 Flash Preview second, Gemini 2.5 Pro third, GPT-5 fourth and GPT-4.1 fifth. The semantic result agrees with the keyword result after removing the incidental word `tool`.
+
+Decisions also detected implicit external actions, respected explicit exclusions of browsing/tools, separated fictional agents from software agents, distinguished session memory from persistent memory, and avoided treating a 200-word “long email” as long-context work on the specified checks.
+
+### Latency and usage
+
+Measured from the local machine, including network and response parsing, sequential requests with no application cache or retries:
+
+| API-call measurement | Result |
+| --- | --- |
+| Requests | 24 successful, 0 failed |
+| Minimum | 228 ms |
+| Median | 447 ms |
+| Sample p95 (nearest rank) | 1,301 ms |
+| Maximum | 1,721 ms |
+| Input tokens | 66,804 |
+| Estimated API cost | $0.0066804 |
+
+Cost uses the [published Decisions input rate](https://developers.openai.com/api/docs/guides/decisions#pricing-and-availability) of $0.10 per million tokens, excluding account-specific premiums. This is an estimate, not a billing invoice. These timings are the extra interpretation call, not deployed Scout end-to-end latency. The first request was the slowest; the measurements do not establish the cause. Twenty-four observations are insufficient to establish production tail latency.
+
+## Failures found outside the initial assertions
+
+Manual review of the complete responses found false positives that the prewritten partial assertions did not cover:
+
+- The fictional-agent story incorrectly received a strict JSON requirement: `yes` probability 0.52, confidence 0.04. It also received structured-output weight 3 despite only 0.42 probability for `required`.
+- The supplied-product comparison incorrectly received a strict JSON requirement: `yes` probability 0.58, confidence 0.16.
+- The codebase review received structured-output weight 3 without an extraction/schema requirement.
+- The two persistent-memory paraphrases received different general capability weights and different rankings. The memory classification itself was consistent, but ranking stability is not solved generally.
+
+An offline sensitivity check requiring at least 0.80 summed probability for positive capability weights removed several questionable tags but reduced the original checks from 65/65 to 57/65. A blanket confidence cutoff is therefore not a validated fix. It was not added to the interpreter. Confidence must be calibrated per decision, and hard exclusion rules need particular care.
+
+## Evidence limitations and next decision
+
+The initial frozen index had zero dedicated memory benchmark series. The Berkeley Function Calling Leaderboard series has zero model matches; agent evidence includes τ benchmarks. Recognizing a memory need does not establish which model handles it best. Memory depends on the model and memory setup, and should remain explicitly unverified until comparable evidence is ingested.
+
+No candidate model processed an invoice, performed tool calls or used a memory store during this experiment. There is no measured downstream task-success improvement. No latency or price preferences were newly inferred or optimized.
+
+The result supports continuing with a decision interpreter, but not deploying this raw prototype as a fully validated ranking improvement. Before production: add comprehensive negative assertions, calibrate hard filters on a separate labeled set, handle uncertain answers explicitly, enforce required API features, add comparable memory/tool evidence, and measure latency from the deployed service. Keep the public data-handling guide accurate when prompts begin reaching an inference provider.
+
+
+## Integration follow-up — 14 October 2026
+
+The production interpreter retains fourteen typed questions. A shorter six-question rewrite lost valid requirements in diagnostic cases and was rejected. Targeted normalization now grounds JSON/schema filtering in prompt wording, removes incidental agent tags when external action is excluded, and separates persistent memory from session state. It preserves consequential uncertainty without hiding valid low-confidence requirements behind a blanket probability cutoff.
+
+Thirty real Decisions calls, including ten additional negation/format/tool/memory cases, passed all 83 selected boolean checks. Median API time was 447 ms, sample p95 897 ms, and maximum 1,064 ms; total input usage was 83,009 tokens. This remains a small, development-informed diagnostic set, not a held-out accuracy benchmark. Captured results are retained outside the repository in the task artifact directory.
+
+The index now includes BFCL v4 native function-calling results and three separate external-memory backends, with strict support/evidence filters. On the captured snapshot, the two memory paraphrases return the same five model IDs despite slightly different generic capability weights. The rank formula remains 80/13/7. API/MCP share one interpreter and never accept client-supplied classifications. No vector database or generative reranker was added.