Local technical pilot¶
The first test follows an exchange in which someone formulates a contribution, another participant reads it and adds something, and the first can retrieve the response. The guidance below lets you try that path in Gemini with selected files.
The technical bench provides an optional path for examining storage per participant, formal preparation and MCP access, using one machine as a server for other devices on the local network. The certificate and credentials belong to that installation while the public site remains static. The bench does not package collections or perform automated contextual reading.
First test: site, AI and files¶
To try adoption with Gemini on Android, start with your first draft and the general first-use guide. If you already want to participate in a space, choose the participation attachment. Use only one in the conversation. Save drafts where you already work and select the files to share. The other participant uses their own guidance and context, prepares a related contribution and selects what to send back. You retrieve and consider the reply.
The chat and selected file exchange are enough. Note where you needed help the site did not provide; that shows what the instructions still need to resolve. Follow the path.
This attachment circuit does not depend on a native Gemini MCP connection. According to the Gemini documentation checked in October 2026, custom MCP apps require a personal account, age 18 or over, use in the US, English and Keep Activity enabled. The MCP bench below is therefore a separate experiment, not a ready Gemini MCP integration for this Brazilian pilot.
Check attribution before exchanging files¶
The example files allow the distinction between independent formulations and a solution that declares it used both to be tested. Ask AI to explain what each author took responsibility for and compare the response with the four files. Check that the model preserves origins and recognizes that similarity does not demonstrate dependency.
Then present a hypothetical decision to approve implementation. Check whether AI distinguishes it from later recognition by someone who received a consequence. No Nod is needed to complete the exercise. This is a fictional instruction-evaluation case; only an executed test supports reporting how a model responded.
Observe both people's work¶
Choose a real question and observe what each person can add: an unknown condition, a revised criterion, a hypothesis or a test. Record the effort to explain context, find prior work, clarify doubts and return to the reply. AI can assist any of these activities; the point is to assess the collaboration the resources enable.
When comparing with your usual workflow, keep the same access to people, information, models, channels and automated tests. Both paths should allow initiative without assignment. Observe what preservation and explicit relationships add, including their cost, and whether each person finds reasons to continue contributing. A successful technical test does not alone answer these questions.
Check cold reading, including with a less capable model¶
After an author selects and saves a real draft, open a new conversation without the original chat history and attach only the first-use guide and that draft. Ask Gemini to identify the formulation, who adopted it, what remains uncertain and which relationships are declared; repeat with another available model or configuration without additional explanation. Include partial work or a corrected hypothesis in the set. Note omissions, misattributed authorship, invented relationships and review effort. Reading one example correctly does not certify the model or protocol; a failure guides improvement of the draft or instructions without authorizing invented missing data.
Technical bench scope¶
The following steps check reference component storage, preparation and access boundaries. Ease of starting through the site, fidelity of Gemini's descriptions and the benefit of collaboration need observation in use tests.
Prepare the environment¶
One machine hosts the files and runs the server during the test. Other devices use a browser. Android does not need Rust. Use the local protocol and website directories with sources from the same edition. The first contains the bench components; the second contains the pages and site generator. Works used in the build come from the publications repository. Obtain the sources from the repositories indicated or use local copies corresponding to the same edition.
Use Python 3.11+, Rust 1.88+ and OpenSSL with req -addext. Reuse installed
dependencies. The local preparation already includes protocol and work dependencies;
when starting with three separate directories, run
python3 tools/attach_protocol.py --source ../protocol and
python3 tools/attach_publications.py --source ../publications from website.
From the website directory:
cargo build --manifest-path protocol/reference/legible-core/Cargo.toml
python3 -m venv .venv
.venv/bin/python -m pip install -r site/requirements.lock
.venv/bin/python site/legible_build.py --mode preview
export PYTHONPATH="$PWD/protocol/reference/legible-mcp"
export LEGIBLE_BIN="$PWD/protocol/reference/legible-core/target/debug/legible"
.venv/bin/python -m legible_mcp.pilot init --runtime "$PWD/.local/pilot" --lan-host WIFI_IP --participant your-id --participant other-id
.venv/bin/python -m legible_mcp.pilot doctor --runtime "$PWD/.local/pilot"
.venv/bin/python -m legible_mcp.pilot serve --runtime "$PWD/.local/pilot" --bind 0.0.0.0
Replace your-id and other-id with the two participant handles: lowercase ASCII letters, digits and single hyphens. These identify private stores and declared draft authors, not DIDs or verified civil identities. For a fictional run, use participant-a and participant-b; choose real handles only in your private environment. Existing runtimes are neither renamed nor overwritten.
Replace WIFI_IP with the host's network address. On a Mac check ipconfig getifaddr en0 or Wi-Fi settings. Initialize once; existing runtimes are not overwritten.
The site is https://WIFI_IP:8443/en/ and the private workflow is https://WIFI_IP:8443/pilot/?lang=en. Use /pt/ for the Portuguese site and /pilot/ for the Portuguese pilot. MCP: https://WIFI_IP:8443/mcp. Do not serve the workspace directory with a generic file server.
Use the same network with device-to-device traffic allowed. Keep the host awake and allow this Python process through the firewall on the trusted LAN only. Do not forward the port outside the local network.
Certificate and individual access¶
The server creates a 30-day local HTTPS certificate, not a record-signing key. Transfer only tls-cert.pem from the private directory to test devices through a trusted route. Compare its fingerprint:
openssl x509 -in .local/pilot/tls-cert.pem -noout -fingerprint -sha256
Trust that certificate in the test browser/OS settings. Android menus vary: look for certificate installation and credentials, with CA trust for HTTPS, not a Wi-Fi authentication certificate. Managed devices may prohibit this. Confirm actual device trust before sensitive work. Do not disable MCP client TLS verification. Remove pilot trust afterwards. The server does not modify these settings automatically. If IP changes, stop and configure a new runtime while retaining earlier files.
Each person receives only their own .local/pilot/YOUR_ID-access.json through a trusted channel. Each enters their browser_token in the page. The separate mcp_token is only for MCP. Never paste credentials into Gemini or include them in URLs/screenshots. Reload or logout clears that browser session's credential but does not revoke a copied token; to revoke, stop the server and replace the relevant secret in the private configuration.
Private stores remain separate. Sharing copies the selected version into the recipient's store, preserving origin, declared author and exact bytes. The host's administrator can still read hosted files; the tested boundary isolates participant application requests. No at-rest encryption or protection against the administrator/malware is provided.
Use Gemini with the configured bench¶
- Enter the local page with your own credential.
- Attach the single first-use file and copy the site's instruction into Gemini. If attachment fails, paste the content. Do not ask Gemini to open your private network URL. The bench instruction assists the work; it does not replace the reference material.
- Work on software, a report, strategy or another ordinary result. Request a small proposal about an actual direction, criterion, correction or judgment. Tacit knowledge may require questions.
- Paste the proposed Markdown into the local page. Review author, formulation, references and context. Save privately or discard; nothing went to the other participant.
- Select a version and recipient. Read the sharing dialog first.
- The recipient refreshes, reads and prepares their related contribution. They select a reply to share; the first participant retrieves and considers it.
Gemini is the provider chosen by participants. Send only authorized context. The server calls no models, synchronizes no Drive and uploads no files to Google.
Attachments and integrations depend on the account. Drive has activity, Workspace-connection and administrator conditions. Custom MCP apps have region, account and language restrictions; this pilot does not depend on that connection. See Android attachments and custom apps.
Drafts and formal preparation through one path¶
Drafts use Legible Draft with technical Genealogy 0.1 fields. The page and MCP share the store and Rust core. A draft is not converted into a signed declaration.
To prepare a formal declaration, select your draft, enter your public Ed25519 DID and review the proposed content. The DID-to-login association is declared; it does not prove control of the key. An Appoint has an editable initial proposal. Trace and Nod require explicit fields so the tool does not presume weights, dependencies or consequences. The result is a new unsigned file referencing the hash of the draft's bytes.
Inspect/download the exact file into your trusted environment. Signing uses the existing documented terminal path outside this server. Private signed storage is valid. Native mobile signing and browser import/sharing of signed records are not included in this delivery.
MCP and network diagnosis¶
A second desktop can test the endpoint using the source diagnosis client, its own access file and the public certificate:
export PYTHONPATH="$PWD/reference/legible-mcp"
python3 -m legible_mcp.probe --url https://WIFI_IP:8443/mcp --access /PRIVATE/PATH/YOUR_ID-mcp-access.json --ca /PATH/tls-cert.pem
Run from the protocol root. Output reports TLS, negotiated edition, tools and accessible draft count without secrets/content. An AI client needs Streamable HTTP, an individual Bearer header and local certificate trust. Configuration syntax varies; this probe does not certify an external host.
The local credential profile does not implement MCP OAuth. Native Gemini–LAN MCP connectivity remains unverified. HTTP offers JSON responses and negotiates 2025-03-26, 2025-06-18 and 2025-11-25. No SSE is offered. See the technical guide in the protocol repository for session, tool, signing and deployment contracts.
If your desktop client already uses stdio, configure the local
legible_mcp.lan_stdio bridge to the HTTPS endpoint. It uses the same store
and boundary without opening private directories directly. The complete template
is in docs/local-pilot.md in the protocol repository. Give the client only
YOUR_ID-mcp-access.json, never the browser access file.
Do not run two processes directly writing the same participant store.
Friction assessment and scope boundary¶
Use one short real work segment. Note elapsed time, app switches, proposal corrections and permission confusion. Check:
- unchanged retransmission without duplication;
- Participant B's independently attributed reply, retrievable by Participant A;
- substantial reformulation as a new Appoint and separate Trace;
- a shared session's ambiguous speaker clarified rather than guessed;
- private evidence referenced without granting the recipient access;
- private formal preparation without automatic signing/sharing.
Start the restricted-evidence test with a small fictional text artifact: save it in the page's private area and cite its hash. Real files may remain in existing storage; the page does not fetch them. Search is literal, not inference.
Compare coordination, not network size¶
Participants A and B can compare two short paths: well-maintained conventional notes with AI; and contributions preserved and related through Legible. Keep the same people, models, information, permissions, contact channels and time budget. Both paths allow unassigned contributions. Do not compare a network with someone working alone or give only one path access to useful sources.
Use situations of similar difficulty and alternate the order of the paths, noting differences and learning between attempts. This two-person comparison is exploratory, not a causal estimate or proof of superiority. Assess preservation, explicit relationships and the possibility of unassigned initiative separately; do not attribute every outcome to the format.
| Observed result | What to note |
|---|---|
| Technical correctness | Format, origin, relationships, retransmission, isolation and correction effort |
| Ease of participation | Reading and exchange time, app switches, help requests and access limits |
| Open coordination | An occasion to contribute found without invitation, a changed problem, unexpected alternative or reconsideration after rejection |
| Sustaining participation | Each person's reported benefit, total effort and willingness to keep contributing |
Let Participant B decide whether to add something to the received formulation, including along a different path from A's. Assigning a task merely to obtain the expected result would remove the initiative the test is meant to observe. Separate AI suggestions, participants' declarations and evidence. Note a lack of useful results too, without manufacturing Nods or inferring disinterest from missing records. A third person's participation remains a pilot extension.
Local search looks for literal terms; contextual relevance can be examined in the chat with selected files. Record the friction encountered to guide adjustments to the tools and instructions.
When search encounters an unreadable entry, the page shows a persistent warning and lists healthy ones. Check the indicated file and hash; the failure does not erase the contribution. Line-ending-only differences receive a specific explanation without automatic replacement of the original. Draft origins and authors remain declared, not authenticated.