Skip to main content

​
Set up Merion from scratch

Merion starts with one private evidence layer for the computer, not one repository. Once recurring, economically meaningful work appears in that evidence, create a workflow factory and turn the strongest examples into reviewed episodes and evaluations.
This page documents the canonical v1 onboarding flow. Package installation and hosted sign-in are not live during private development.

​
1. Install and sign in

Install the CLI, then authenticate through your browser:
Sign-in connects your identity, organization, and dashboard. It does not automatically upload raw work evidence; each factory’s policy governs what can leave your machine.

​
2. Set up Merion on this computer

Configure one local evidence lake for work across folders and harnesses:
Setup detects Codex history, OpenCode history, a user-installed Screenpipe API, and Merion’s localhost telemetry receiver. It automatically performs a low-cost catalog pass and returns the next unresolved setup action. Merion stores compact references and metadata; it does not copy raw harness histories, screenshots, audio, OCR text, or prompt bodies into its index.
Setup does not modify Codex settings, install Screenpipe, or start a login service without your approval. See global capture for live telemetry and all-day capture.
For an agentic caller, the same command returns structured capabilities, approval boundaries, and one next action:

​
3. Connect live context

Persistent capture is an explicit choice:
The first command starts the low-priority, event-driven receiver at login on macOS. The second prints the authenticated Codex configuration for review; it does not edit user settings automatically. Screenpipe remains an independently installed optional source for desktop context.

​
4. Find and label meaningful work

Work normally in any folder, app, or harness. Then inspect and label a time window:
The label supplies human meaning and economic context. It does not automatically turn nearby telemetry into a benchmark or training example.

​
5. Choose local-only or governed cloud analysis

Local-only is the default. Confirm the boundary at any time:
When a personal or organization workspace needs larger storage, compute, or background analysis, create a metadata-only policy and inspect a bounded plan:
Planning is read-only. merion cloud queue --since 24h --approve places an immutable metadata manifest in the local outbox, but the private-alpha CLI has no production cloud transport and performs no network upload. Raw source is a separate tier and always requires per-manifest approval. See governed cloud sync for tenant, retention, encryption, and data-use boundaries.

​
6. Create a workflow factory

A factory is the durable learning boundary for one real workflow. It contains the workflow’s sources, data policy, work episodes, evaluations, experiments, and engineering decisions.
For an explicit, agent-friendly setup:
The target can be a new directory, an ordinary folder, or a Git repository. Initialization creates private .merion state. It does not initialize Git, create a GitHub remote, or publish your evidence.

​
7. Ask Merion what comes next

merion next returns one evidence-backed action, why it is next, and any decision that must remain human-accountable.

​
8. Start genuine work

Start the episode before its solution is known:
Merion asks for the original task, workflow family, recurrence, economic value, and harness. Continue doing the work in your existing harness. For an agentic caller:

​
9. Close the outcome loop

After the work is complete:
The closure interview records whether the result was accepted, what required correction, what would have made it unacceptable, and how an independent reviewer could recognize success.

​
Success criterion

You are done when the episode contains a defensible starting state, a real trajectory, and human-reviewed outcome evidence. Continue with capturing real work to understand what makes an episode useful for evaluation engineering.
Last modified on August 25, 2026