Evidence and Replication: From One Sony to Independent Field Work

16.1 Installation failure, recovery and a repeatable development path

Android software experimentation includes toolchain compatibility, build errors, permissions, physical USB/ADB connectivity, app package versions and recovery after failure. The Sony H4493 running Android 9/API 28 hosted separate research apps for NFC writing, USB camera/glasses and limited MCP Phone access. Gradle build PASS, signed APK, installed version and visible screen are each meaningful evidence objects, but none proves that a physical user's Work was completed. When an installation fails or is repaired, a repeatable record must identify the code revision, signer, host environment, phone model, exact error, operator, successful recovery and unchanged coexisting applications.

The recommended stages are SOURCE_READY → BUILD_PASS → DEVICE_INSTALLED → INTERFACE_DETECTED → ACTION_READBACK → HUMAN_ACCEPTED. A future device may fail at any stage even if the Sony passed it, because USB host support, Android permissions, hardware drivers and security policy differ by model. Recoverability includes not deleting unrelated user data, removing temporary ADB forwarding, preserving test artifacts and refusing unqualified actions. An APP_INSTALLED badge must never be presented as a physical capability acceptance [H1–H3].

16.2 NFC writing and the distinction between user confirmation and independent readback

An NFC NDEF record can carry an HTTPS address that compatible phones use as a low-friction physical entry. The user had earlier reported a Sony NFC write, and a separate cable/tag test whose iPhone tap opened a page. These histories do not automatically establish a byte-for-byte independently verified writer-to-reader transaction. GiftReality Android NFC Writer A0-001 later achieved a compiled, signed and publicly downloadable APK with HTTPS and browser checks, but its local handoff explicitly marks real Android tag write and independent readback as pending. Likewise, the early Windows USB-reader studies and NFC Product 003 page remain separate evidence [H4, H5].

An accepted test identifies the writable NFC tag, obtains consent for the exact intended URI, observes a real write, independently reads the NDEF record, compares the bytes or URI, then checks the actual phone tap and browser destination on a second compatible device. Keep the tag's UID, a product identifier, verified product authenticity, human identity and a Work grant separate. A URL opens information; it does not convey permission to perform work, install device management or spend money. QR, readable HTTPS and human assistance stay available for people without NFC [E1].

16.3 USB-glasses preview, the photo-save failure and the remaining capture acceptance

The P0-001 Sony USB-glasses app was built and installed, with an initial inspection reporting no USB camera while the glasses were not connected. The subsequent P0-002 handoff records user-confirmed live preview of the USB glasses on the earlier app, but not an independently frame-hashed camera acceptance. Pressing Photo caused an actual crash; device logs identified an older UVC library's MediaStore permission failure. This distinction matters: seeing a preview does not prove that a usable image was saved or delivered [H2, H3].

The P0-002 repair preserved UVC preview libraries and replaced the older takePhoto path with a TextureView bitmap snapshot, JPEG encoding and an app-specific Pictures save. Build, lint, reinstall and a no-camera refusal test passed. The actual repeated USB-glasses preview on P0-002, decodable JPEG, orientation, image quality and acceptance by a receiving person were still pending. The snapshot is a rendered preview frame, not necessarily a full sensor-resolution photograph; an app-private saved image could be lost on uninstall [H3].

16.4 MCP battery access, one-tap approval and rejection of ungranted tools

The Sony MCP Phone project deliberately used only Android INTERNET permission for its limited loopback server, without granting camera, NFC, contacts, microphone, location or SMS. It offered explicit read-only device-profile and battery tools. The P0-001 handoff recorded build and UI acceptance while a positive Mac/owner token call was not yet verified. P0-002 introduced an owner-visible pairing dialog scoped to one tool, and the later P0-003 handoff records user-confirmed pairing and a real battery reading. Results belong to their actual experiment revision rather than being backdated [H1, H6, H7].

The security boundary must reject missing or wrong bearer tokens, unrelated tools such as contacts, untrusted browser Origin, ungranted calls and requests after timeout or owner Stop. A temporary Mac USB-forward to the phone's loopback port can enable a test without exposing the device as a worldwide server. Pairing from a familiar computer is not the same as cryptographically establishing its identity. An MCP tool list is a catalogue of candidates, not permission to reach additional phone resources through a model prompt [E2, E3].

16.5 Human-tested revocation, outstanding security tests and lessons transferable to other devices

A P0-002 human-interface defect left the Stop button disabled after automatic session closure; a non-cancelable pairing dialog could also hide the ability to revoke while a prompt was open. P0-003 kept Stop/Revoke enabled even in the OFF state, exposed Stop All MCP inside the modal, and explained already-revoked status. The revised APK installed on Sony. An ADB tap of the OFF-state control plus a USB loopback readback found no active listener, and temporary forwarding was removed. These are real bounded observations, not proof of every active-session case [H7].

Still pending in that handoff were a fresh active grant, a real owner finger press, independent rejection of the exact old token after the revised user interaction and the live modal stop-all case. Such tests must be witnessed separately: a server-side timeout does not prove an accessible human can stop ongoing work. Reproducible design needs default-deny, short-lived grants, clear human control, truthful audit receipts, safe handling of in-flight actions and a published list of untested risks.

17.1 Authorized sample observation and evidence-backed product information

A low-risk physical Work can start when the lawful holder permits inspection of a particular sample and asks a focused question: identify the documented connector, explain safe-use instructions or report an observed part condition. The task records sample custody, expected Reality Delta, appropriate measurement or visual instrument, available source documentation, time limit and responsible reviewer. The result should distinguish verified manufacturer information from directly measured conditions and the model's tentative interpretation.

An e-Person can prepare accessible language and a Work graph but must not claim inspection if the camera was unavailable or the source record absent. A useful outcome may be a dated report, an accessible explanation, a request for a skilled technician or a clearly justified refusal. It should not depend on buying a new phone or an AI subscription; a shared qualified station or human assistant can perform the same bounded work where service is genuinely available.

17.2 NFC-based physical-to-digital work handoff

NFC/QR/HTTPS can connect an authorized physical product to a public information entry and, optionally, to a narrow Work request. Distinguish Tap to Understand, Tap to Verify and Tap to Act. Understanding may show clear instructions without login; verification checks a trusted source or necessary authentication; action asks for explicit purpose-bound human authority. Reading a tag, scanning a code or opening a page never creates an e-Person identity or grants control of a phone, heater or supplier account.

The acceptance chain requires the actual NDEF write, independently read URL, cross-device tap and HTTPS open, accessible content, provenance check, a separate user intent, scoped Work authority and a human-accepted result. The first Accessible Product Passport trial can use a neutral cable or package without licensed trademarks. A FIFA 2027 branded variant requires independent Pannex customer and rights-holder approval for physical marks, digital content and sales territory, which a successful NFC test cannot provide.

17.3 Local inspection, learning and supervised visual assistance

A person may need help recognising a low-risk part, reading a small label, understanding assembly direction or finding a repair service. A qualifying Work may use a suitable phone camera, USB glasses, an accessible Hub or a trained worker when each is actually available and authorized. The intended outcome is a supported understanding or decision, not automatic certification of safe traffic navigation, mechanical operation or medical advice. The camera's interface, data rights and evidence must be checked for that specific task.

Accessibility means easy-to-read steps, voice or larger controls when needed, clear choices, an option to correct the model and a reachable human supervisor. InnoSpire's published vision, speech and inclusive-interaction experience motivates candidate collaboration but does not give HSIMC ownership of its hardware or prove a particular deployment. The participant must be able to reject the AI's interpretation; a model's confidence does not replace a human inspection in consequential contexts.

17.4 For each template: intended outcome, required capabilities, consent, evidence and acceptance

Each Work template carries a versioned mini-contract: person and purpose, target Reality Delta, eligible capability and provider, site/time, consent and data constraints, accessibility route, expected action, safe stop, evidence objects, supervisor, cost and human acceptance criteria. The Work graph may identify missing materials, permissions, calibration, skills, a valid network or an alternate entry. These missing conditions should spawn bounded child Works rather than be silently presumed available.

A template's publication does not make a specific device READY. Separate TEMPLATE_DEFINED, DEVICE_QUALIFIED, PERMISSION_GRANTED, ACTION_OBSERVED, EVIDENCE_VERIFIED and HUMAN_ACCEPTED. A phone may display an App but reject USB access, an NFC scan may open the wrong origin, and a camera may preview but fail JPEG saving. Each failure is useful, provided it is attached to the actual device, sample, revision and correct acceptance stage.

17.5 Progressing from a successful tool call to a result another person can use

A correct JSON response to phone.get_battery verifies one bounded tool call, not that an individual achieved a productive outcome. Ask whether the reading answered their stated question, whether the method and timestamp are trustworthy, whether it can be understood in their preferred accessible form and whether another person can act on the result safely. Successive prompt completions and repeated tag scans are activities, not counts of human-accepted Work.

The chain is Intent confirmed → authority granted → Reality qualified → actual action and readback → evidence verified → beneficiary acceptance or correction → authorized continuation. A spoken summary may be more useful than a machine field, a measured PD trace more useful than a sales claim, and a safe refusal more useful than fabricated certainty. Productivity must be measured at the person's completed decision or usable service.

17.6 A sample question resolved while the exhibition decision window remains open

At a trade show or short buying meeting a customer may ask whether one cable safely supports simultaneous power and data, whether an NFC product opens the intended authorized URL or whether the instruction is accessible to someone with low vision. A narrow Work defines the actual available time, sample custody, decision maker, qualified test equipment and what acceptance would mean. Parallel preparation can find official specifications or arrange a demonstration while a specialist verifies the physical sample.

Before the meeting ends, the result must separate observed evidence, supplier claims, rights restrictions and what remains to be tested. If calibrated PD tracing, multi-output loading, independent tag readback or user accessibility testing is missing, state that limitation and propose a qualified next test. A decision within the window may be 'not verified yet'; neither deadlines nor marketing enthusiasm make an unsafe, unauthorised or unmeasured assertion true.

17.7 Trade continuity through qualified correction, adaptation or safe discontinuation

One physical product can continue to provide value after sale through revised accessible instructions, approved accessories, confirmed compatibility, authorized repair, local support and responsible recovery. The Work interface can point to these services without requiring established suppliers or global customers to accept HSIMC's entire mother architecture. Manufacturing, licensing and digital service rights are separately controlled by their rightful operators.

If a sample is unsafe, the origin of content cannot be verified, the accessible service is ineffective or a licensed feature lacks approval, a qualified STOP or correction is a valid business result. Publish the non-sensitive lessons with their evidence, preserve actual customer relationships and avoid treating rejected work as a lost opportunity to count. Product-to-service continuity earns trust only through independent human acceptance.

18.1 Another phone, another operator, another place—the same bounded Work

A credible replication trial begins with a defined Work and evidence checklist, not an undocumented explanation from the founder. An independent operator takes another eligible phone or supervised Hub, verifies supported interfaces and safety, requests fresh authority from the equipment holder and completes one low-risk useful job. Include local language and accessibility arrangements; they are part of the experiment, not a reason to exclude participants whose conditions differ.

Record model, firmware, adapter, time, connection, operator identity, purpose, allowed data, observed readback, failure paths and the accepting beneficiary. The Sony's original test can be a comparison reference but provides no transferable token or blanket compatibility. Replaying a stored JSON answer or presenting a different person's earlier NFC image is not a second independent physical test.

18.2 Reference cohorts, compatibility matrices and explicit unsupported cases

Organize trials by actual device/OS cohorts, NFC read and write support, USB host compatibility, battery safety, local-versus-cloud connectivity, accessibility route and trained supervision. Keep a matrix showing qualified features and explicit unsupported conditions. For instance, a phone might read NDEF but not write a selected tag, a USB glasses model might preview but fail to save a photo, or a shared site might have no permitted internet. Each needs its own acceptance record.

Count failed and unsupported attempts, not just successful demos. Verify whether QR, speech, a second phone or a community Hub genuinely helped the participant finish the intended Work, rather than merely displayed a fallback page. The United Nations and ITU population estimates inform inclusion priorities, but they cannot be substituted for a measured compatibility sample of ten billion handsets [E4].

18.3 Active-grant, revocation, concurrency and protocol-migration test suites

A minimum technical suite tests deny-by-default; grant only one tool; wrong or missing bearer; unrelated Tool rejection; browser Origin checks; session expiry; live human Stop/Revoke and old-token denial; restart and safe physical stop. Sony P0-003 already showed an improved UI, an OFF-state tap and absence of the listener after stopping. The stronger live owner finger interaction and same-token invalidation test remained pending and must not be marked PASS by implication [H7].

Further test independent requests that arrive concurrently, repeated messages, transport loss, stale authority after restart, a changed device or operator, software update and protocol-version migration. MCP's callable interface does not automatically give a persistent Work ledger or resolve duplicated physical actions. Each positive and negative test must identify its actual client and server build, observed output and independent readback, with human supervision when a real device can move or energize.

18.4 Distinguishing registry size, installations, active nodes and productive utilization

HSIMC once recorded 356,782 addressable Runtime directory references; those are registry records, not 356,782 verified operating services or locations [H0]. A downloadable APK is distribution readiness; an install means package presence; a local MCP listener means reachability; a read-only battery response proves one callable observation. A Ten-Billion-Phone aspiration likewise does not establish that ten billion devices are currently compatible, consented or economically productive.

Report separately reference identities, inspected devices, functioning limited Tools, active human grants, distinct participants, verified outcomes, refusals, independent replications, ongoing maintenance and per-accepted-Work cost. Never sum categories or count repeated taps as new participants. The No One Left Behind condition should be tested with people beyond habitual mobile-internet use through qualified accessible and human-supported entry routes.

18.5 An evidence register that preserves failures and prevents unearned readiness claims

A useful public evidence ledger includes artifact ID, source and revision, operator, sample and physical custody, phone/OS, timestamp, permitted scope, test input, expected result, observed result, machine readback, user's separate statement, errors, independent confirmation and the true next gate. Use labels such as BUILD_PASS, USER_REPORTED, MACHINE_OBSERVED, INDEPENDENT_READBACK, HUMAN_ACCEPTED and PENDING. Do not silently rewrite a prior failure once a later revision is installed.

Sensitive owner identifiers, temporary bearer tokens and photos need redaction and lawful storage. A SHA256 proves document-byte integrity, not the truth of a physical claim; similarly, an accessible user's positive report is real evidence of experience but may not certify safety or replication. Publishing honest negative outcomes prevents wasted engineering effort and protects participants. The ledger itself is a growing global resource when other qualified teams can understand and reproduce it.

Non-executable independent replication evidence template ↗

18.6 Sample identity, custody, conditions and distinct acceptance objects

Assign distinct specimen IDs for each NFC tag, cable, phone, external peripheral, fixture and physical site, separate from e-Person and Work identities. Record who held each item, relevant material and device version, whether consent allowed testing, energy and network conditions, environmental state, data retention and who witnessed the result. One old phone can be part of several experiments, but a successful NDEF read from one tag never proves another tag is authentic or already written.

Acceptance belongs to explicit stages: SOURCE_ACCEPTED, BUILD_ACCEPTED, DEVICE_INSTALL_ACCEPTED, INTERFACE_OBSERVED, PHYSICAL_OUTPUT_READBACK, INDEPENDENT_REPLICATION_ACCEPTED and HUMAN_WORK_ACCEPTED. A person may accept a useful explanation while material certification remains unverified; the scope must be shown. The genuine start of global scale is one small, properly authorized capability reproduced by another operator and accepted at another eligible Reality.