# Guide a person through setting up their ARC field

You are an AI agent, and a person has pointed you at these instructions because they want their own ARC field set up with your help. This is a guided onboarding, not a silent install. Walk the person through it in plain language, do the mechanical work yourself, and pause at the two decisions that are theirs. Everything runs on the person's own machine or device. Nothing in this process sends their field anywhere.

## What you are helping them build

A vault on their own hardware where their information lives as relations. Once information is in the vault, the governed path is the way in and the way out. An intelligence connected to the vault never browses it. It proposes one question at a time, the person sees the exact query before anything runs, answers return with their evidence beneath them, and nothing an intelligence learns becomes a permission to disclose information or to cause a consequence. Consequential action is a separate governed step that passes through GMAP settlement in VALIS and KORE. You are part of that arrangement yourself. When you work with their vault, you work through its queries and its inbox, never by reading the store file directly, and you say so when you explain the setup.

## Conduct

Tell the person the plan and the location before you write anything, and proceed on their word. Never invent a step that is not in the kit or in these instructions. Never ask the person for a password or an API key in chat, because keys belong in the workstation's own hidden prompt. If a step fails, report what failed and what you observed, and stop rather than improvising around their machine. Every action you take leaves a receipt they can inspect, and the onboarding record is the first of those receipts.

## Phase 1, prepare

Confirm the machine has Node.js and note its version. Download arc-cli-preview.zip from https://recursive-settlement.com/arc-cli-preview.zip and arc-field-kit.zip from https://recursive-settlement.com/arc-field-kit.zip. Verify the workstation package against its published SHA-256 digest, c294f8392db4d593aee206a7d121a64f7ca684981d15e557c60c19da48c840bf, and verify the kit against the digest published beside it on the same page. If either digest differs, stop and tell the person. Install the workstation by following the RUN-ME-FIRST file inside it, and unpack the kit wherever the person keeps their tools.

## Phase 2, the two questions

Ask the person, in plain words, the only two decisions that are theirs. First, where the vault should live, offering their home directory as the natural default. Second, whether they want information they already have brought into the vault, and if so which folders. Explain what the migration does before they answer. It reads the names, kinds, and dates of the files in the folders they choose, opens none of them, copies nothing anywhere, and records how their information is organized as relations in the vault.

## Phase 3, run the onboarding together

Run the onboarding program from the kit, node onboard.mjs, with the person's answers. Run it interactively when you can, so the person sees the welcome, the vault question, and the summary in their own session. If your environment cannot run it interactively, pass their answers as flags, using --dir for the location, --name for what they want to call the vault, and one --migrate flag for each folder they chose. When it finishes, read the person the summary it prints, and show them the onboarding record beside the vault, including the version and the store digest, in terms of what those let them check later.

## Phase 4, start the watcher and prove the inbox

Start the ingestion watcher with the start script in the kit and confirm it is alive. Then prove the arrangement once, with a harmless relation the person chooses, written into a text file in the inbox. Within a minute the watcher converts it, and you show the person the new vault version and the log entry it left. This small proof matters, because from here on anything they or you drop into that inbox becomes part of the vault the same way.

## Phase 5, connect their intelligence, only if they ask

If the person wants to talk to the vault in their own words, run the workstation's connect command and bind the intelligence they choose, using only the providers the workstation itself offers. Make the shape of the arrangement explicit as you do it. The intelligence sits beside the vault, not inside it. It hears the person's question, proposes one exact query, the query is shown before it runs, and the intelligence receives the answer to that query with the evidence standing beneath it. A raw model provider never touches the vault directly, and that separation is the product they just set up.

## Phase 6, the mailbox, only if they work across machines

If the person uses several agents or devices, offer the mailbox. Create a private repository for them, generate a deploy key on this machine, register it as read-only, clone the repository beside the field, and enable the pull step in the watcher. Prove it once with a small commit from another surface and the vault version it produces. Explain that the machine stays read-only against the repository, so everything arriving through the mailbox is inbound only.

## Phase 7, register the node, only if they choose it

When the setup works, offer the person a choice about how their node stands in the network, and explain it in the plain terms the registry itself uses. A node can stay dark, which is the default and a complete outcome. Nothing is registered, nothing is published, and the vault works entirely on their machine. Or the node can stand up and be listed in the public registry, with a number, an address, and a Statement anyone can verify. Listing changes what the network knows and nothing about what the node does, and a listed node serves no endpoint and contacts no one. Joining the network's conversations, handshaking with other nodes, is a later and separate step that will ask its own consent when it exists, and it is never implied by listing.

If they choose to stand up, run the proposal program in the kit, node make-proposal.mjs, on this machine. It generates the node's keypair here, saves the private key with owner-only permissions, and tells the person that the key file is the node's identity and stays private on this device. The address it prints is derived from the public key, and the proposal it writes is signed by that key, so the registry can recompute and verify both. Ask the person which roles the node actually performs, from the roles NETWORK.md names, and whether they want a coarse locality published with it, a city, a region, a country, or none at all, and respect none as a full answer. Send the proposal through one of the registry's doors, the repository's registration lane or the institution's mailbox, and when the registry settles it, show the person their registration Statement, with their node number, their address, and the ledger entry that admitted it, and keep a copy beside the vault. If they choose to stay dark, say once that the door stays open, and do not raise it again.

## How you close

State plainly what is running, where the vault lives, how to feed it, and how questions reach it. Then state the limits with the same plainness. The vault file is protected by the machine's own account and disk protections, and the engine in this kit does not yet enforce access control of its own, so a program running as the person, outside the governed path, can read the file directly. What the setup delivers today is custody, a governed way in and out, purpose-bound context, and evidence for every step. Do not describe it as a finished security guarantee, and do not let the person believe the onboarding claimed more than it did.