# MEOK completion handover **11 November 2026 · Research handover, not release permission or a declaration that the whole platform is finished.** ## The practical conclusion The research toolchain is usable within its documented scope: pinned numerical inference, receipt export/import/recomputation, cross-runtime reproduction, static delivery and dated release-consistency checks have retained execution evidence. The next decisive milestone is not another replica or benchmark badge. It is a narrowly defined pilot whose source/access context, individual reviewer, exact approved action and independently observed effect are real and correctly bound. There are three different finish lines: | Finish line | What has to be true | Current assessment | |---|---|---| | Reproducible research demonstration | A reader can inspect the pinned sources, reproduce the supported calculations, see failures and verify the disclosed artifacts | Existing scoped execution evidence recorded; not a perpetual live-health promise | | Bounded external pilot | A consenting recipient completes a defined use case with trusted source/access binding, genuine human authority where needed and a safe failure path | Held pending owner and human acceptance | | Production use or broad industry claims | Task quality, privacy, security, operations, commercial/recipient acceptance and exact release governance satisfy the selected use case | Not established by this research release | The machine-readable order is `handover.json`. It assigns work to existing role owners; it does not appoint people, grant roles, issue credentials, merge branches, spend money or create a new scheduler. The offline `check_handover.py` checks this package's consistency only. ## What was checked in this pass The Apple M4 and current public/private Hugging Face revisions were read. The private Space was running at its inspected source/serving revision; that metadata observation is not a fresh test of chat quality, saved data or every MCP tool. The active model task-contract work and the separate source-currentness work were identified and left unchanged. Existing source/release roles remain with their owners. A current read of the public HITL metadata returned `operator_identity: NOT_VERIFIED`, `human_presence: NOT_ESTABLISHED`, a caller-supplied operator label and `execution_authority: false`. The endpoint reports a configured operator token, signing key and store, but those facts do not authenticate an individual or establish a genuine human approval event. Only assessment metadata was retained; no individual decision or private record was copied. The existing **HITL Authority → Effect Profile** remains the canonical candidate structure. Its own documentation distinguishes proposal, approval, invocation, effect and verification, and explicitly says schema validation does not authenticate the principal or prove the action's scope executed. Its exact source revision and digest are in `existing-profile-pin.json`. No replacement authority schema was introduced here. The completed dataset diagnostic found no within-split exact duplicate feature vectors in the 1,600 training, 400 validation, 560 original-test and 640 later-stress rows. No exact input overlap appeared in the five checked cross-split pairs. The validation-versus-stress pair was not included in that completed pairwise check; no global semantic-contamination clearance is claimed. A follow-up control-state-support analysis was blocked by the tool safety check and was not rerun through another route. The results do not explain away the retained large model error or establish real-world generalisation. ## What still needs doing, in execution order ### G0 — Fix the pilot scope and spend boundary The release/spend owner selects one intended task, recipient class and failure policy. Keep the current no-new-paid-compute constraint unless the owner explicitly approves a bounded exception. Use the existing machines and retained research outputs for preparation; do not launch new jobs merely because more tools are available. A separate source-currentness qualification record marks an existing `cpu-basic` Hugging Face job as billable. Read-only Jobs inspection confirmed job `csoai/6af404d09737d9a9e0929f56` completed on 11 November, from 06:01:52.260 to 06:01:57.046 UTC. The exact charge was not returned. Therefore this pass can truthfully say **no new paid compute was started by this pass**, but cannot say the whole programme has never used paid compute or that its total cost is zero. `compute-boundary.json` preserves that distinction. No job was cancelled, retried or reconfigured. **Exit:** named use-case owner, stated acceptance protocol, approved resource boundary, and no unqualified global cost claim. ### G1 — Bind trusted source, runtime and access The public source-currentness checker and distribution checker solve different limited questions. One checks selected public source bytes; the other compares a reviewed release across named surfaces. Neither establishes the identity of the live private executing process or a user's current right to use a resource. The existing host/access owner must supply the trusted expected source, policy and tenant identities. A caller must not choose the expected trust root, authority epoch or privileged source generation. Recheck access, expiry, revocation, dependency completeness and version at the moment of use. A cache hit must not bypass those checks. Source changes or unavailable verification cause a hold, not an invented match. **Exit:** the actual host path demonstrates that caller-controlled expected identity, stale source/access decisions, revoked access and incomplete dependency coverage cannot be accepted. Existing schema and source ownership are retained. ### G2 — Authenticate a real individual and separately authorise their role Use the existing identity/session integration, not another locally generated identity issuer. A provider login may authenticate an account; it does not by itself appoint that person as an approver or establish a professional qualification. Role, tenant, permitted action, expiry and revocation must be explicit and separately reviewed. Hugging Face documents a real OAuth flow and a sign-in component for Spaces. That is an available implementation route for its owner, not a claim that this handover enabled it or completed the human ceremony. The required identity assurance depends on the selected pilot. NIST's identity guidance separates proofing, authentication and federation; this project is not claiming NIST conformance. **Exit:** a real person completes the intended authentication flow; the existing authority owner assigns a narrow, revocable role; tests cover missing/invalid session, wrong tenant, wrong role and revoked/expired grants. A shared token, agent-driven click or fixture key is not relabelled as a genuine human participant. ### G3 — Prove one harmless approval-to-effect journey Choose one exact harmless action under the existing executor—such as creating a predetermined test marker in an explicitly approved disposable location and reading it back. Do not use payments, publication, email, production configuration or private user records as the first acceptance exercise. The proposal fixes the action, inputs, target, source/policy/authority epochs and digest. The actual authenticated reviewer sees and approves that precise proposal. The executor checks scope, expiry, revocation and replay before it runs. A different observer checks the resulting effect, not merely the executor's HTTP success. A separate reader must be able to verify the disclosed evidence. Preserve denied, failed and partial attempts as well as success. **Exit:** actual proposal, scoped human decision, invocation, independently observed effect and verification records compose under the existing profile. Include changed-after-approval, expired, revoked, duplicate/replayed, wrong-scope and partial-failure controls. A demonstration driven entirely by the same agent is not outside human acceptance. ### G4 — Qualify task capability without hiding failures Let the active task-contract/model lane finish its existing comparison. Do not run a competing experiment against the same queue. Freeze protocol and candidate before fresh evaluation. Record attempted cases, malformed outputs, provider/quota failures, refusals and correctness separately. Select quality and abstention criteria for the intended task—not a universal threshold invented after looking at the answers. The approximately 75-percentage-point original-bank failure of the synthetic process model remains in the research record. The separately fitted head's mean improvement does not justify general deployment. The deterministic generator remains best for its own known process. Software-contract tests, successful artifact replay and model capability are different evidence. **Exit:** agreed task-specific acceptance is met on a genuinely new sample, or the feature is held/refuses outside its established scope. Frozen evaluation examples do not enter training or EAT learning merely because they are available. ### G5 — Complete data rights, privacy and storage lifecycle The public synthetic model/data notices are retained, but that does not clear the entire 100-candidate inventory or all future EAT sources for training. Each intended dataset needs source, rights, consent where applicable, purpose and split lineage. Academy practice answers are not automatically training data. The existing storage owner should qualify create/read/update/export/restore/delete and retention boundaries in an explicitly authorised test workspace. Confirm tenant isolation, access changes and user-visible failure/recovery. Do not copy private conversations into a public evidence bundle to prove persistence. **Exit:** the chosen pilot's data sources and lifecycle are documented and tested. Unknown rights remain excluded; delete/restore claims are tied to actual tests, not configuration presence. ### G6 — Finish canonical release, operations and rollback Existing source and release owners reconcile open, conflicting or draft source changes. This handover does not merge protected branches or treat an isolated source candidate as production. Any tool/security-blocked browser or execution case remains unrun until resolved through its authorised process, not bypassed by another route. Qualify the exact accepted source and deployed version. Test a bounded rollback and user-visible recovery from service/quota/storage failures. Define a support owner, error retention/redaction, release correction path and an operating-cost ceiling. A dated mirror must not silently claim every subsequent source update. **Exit:** owner-accepted source/serving parity, exercised recovery/rollback, supported operating limits and no unresolved deployment blocker in the agreed scope. ### G7 — Obtain outside-recipient acceptance A named, consenting recipient who is not a test identity controlled by the builder completes the agreed journey and independently reproduces an output. Record what was useful, what failed and whether the stated acceptance was met. Do not count internal downloads, author-driven browser automation or repeated test executions as external adoption or customers. **Exit:** independent recipient evidence for the chosen task, with its protocol, failures, limitations and support path retained. This is different from signing a self-produced report or matching the same code on another CPU. ### G8 — Owner-reviewed promotion and optional measurement admission The release owner reviews the exact candidate and residual risks after the relevant earlier gates. Formal GSPC admission is a separate per-axis process and never grants execution authority. A 34-axis roster is not 34 tested measurements; a source inventory is not an audit of every candidate; a research paper is not product certification. **Exit:** explicit owner decision about a defined release and its applicable measurements. No automatic promotion, signing, protected merge or all-industry/ASI/RSI claim follows from this handover. ## Work that is intentionally not duplicated The numerical verifier, receipt-file round trip, independent Python replay, Kaggle execution, Cloudflare static preview, private specialist receiver, Academy learning paths, source-currentness implementation and active task-contract experiment already have owners and retained evidence. This pass links them and narrows the next acceptance, rather than creating another runtime, model server, scheduler or competing approval service. The fastest honest path is **one task, one authenticated reviewer, one exact harmless action, one independent effect observation and one outside reader**. Broader automation and industry coverage should follow that demonstrated path, not substitute for it. ## How to inspect the handover Download this directory and run: ```sh python3 check_handover.py python3 test_handover.py ``` The first command checks fixed-file hashes, nine ordered work packages, required evidence references and non-authorising flags. `HANDOVER_CONSISTENT` means the planning document is internally consistent; its output still says `production_ready:false`, `pilot_approved:false` and `execution_authority:false`. It performs no network requests, jobs or model calls. The second command tests that malformed or self-promoted documents are refused. A hash manifest obtained from an untrusted author is not a signature or proof of truth. ## Primary implementation references Existing project profile and pinned source: `existing-profile-pin.json`. NIST Digital Identity Guidelines: https://csrc.nist.gov/pubs/sp/800/63/4/final . Hugging Face Spaces OAuth: https://huggingface.co/docs/hub/spaces-oauth . Recorded public source artifacts: `source-references.json`. These references guide implementation and scope; they are not endorsements or certification of MEOK.