---
fragment_peers:
  certificate-and-individual-access: certificado-e-acesso-individual
  check-attribution-before-exchanging-files: conferir-a-atribuicao-antes-da-troca
  check-cold-reading-including-with-a-less-capable-model: verificar-a-leitura-a-frio-inclusive-em-um-modelo-menos-capaz
  compare-coordination-not-network-size: comparar-a-coordenacao-nao-o-tamanho-da-rede
  drafts-and-formal-preparation-through-one-path: rascunho-e-preparacao-formal-pelo-mesmo-caminho
  first-test-site-ai-and-files: primeiro-teste-site-ia-e-arquivos
  friction-assessment-and-scope-boundary: avaliacao-de-atrito-e-limite-desta-etapa
  local-technical-pilot: bancada-tecnica-local
  mcp-and-network-diagnosis: mcp-e-diagnostico-na-rede
  observe-both-peoples-work: observar-o-trabalho-das-duas-pessoas
  prepare-the-environment: preparar-o-ambiente
  technical-bench-scope: escopo-da-bancada-tecnica
  use-gemini-with-the-configured-bench: usar-gemini-com-a-bancada-ja-configurada
lang: en
peer: pt/pilot/
shared_fragments: false
title: Local technical pilot
---

# 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](first-draft.md) and the general first-use guide.
If you already want to [participate in a space](get-started.md), 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](get-started.md).

This attachment circuit does not depend on a native Gemini MCP connection.
According to the [Gemini documentation checked in October 2026](https://support.google.com/gemini/answer/17209137?co=GENIE.Platform%3DAndroid&hl=en),
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](participation.md#exchange-example-a-software-improvement) 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

<button type="button" data-open-local-pilot hidden>Open the pilot page on this local server</button>

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](https://github.com/LegibleProtocol/protocolDev)
and [website](https://github.com/LegibleProtocol/websiteDev) 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](https://github.com/LegibleProtocol/publicationsDev)
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:

~~~sh
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:

~~~sh
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

1. Enter the local page with your own credential.
2. 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.
3. 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.
4. Paste the proposed Markdown into the local page. Review author, formulation,
   references and context. Save privately or discard; nothing went to the other participant.
5. Select a version and recipient. Read the sharing dialog first.
6. 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](https://support.google.com/gemini/answer/14903178?co=GENIE.Platform%3DAndroid&hl=en)
and [custom apps](https://support.google.com/gemini/answer/17209137?hl=en).

## 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:

~~~sh
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](https://github.com/LegibleProtocol/protocolDev/blob/main/docs/local-pilot.md) 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.

[General setup](configurations.md) · [Formats and states](drafts.md)
