How DataVizor^™ works

A distributed ledger kept by a globally distributed network of servers. A ledger is an append-only record: entries are added, never edited in place. This one is not kept by a company's database but by many independent servers, spread across regions and operators, each holding a full copy. When DataVizor says something is recorded in the Matter Ecosystem, it means every one of those servers holds the same entry.

Byzantine-fault-tolerant consensus: the servers agree before anything is written. Before an entry is written, the servers run a byzantine-fault-tolerant consensus protocol — a way of agreeing on the next entry that keeps working even if some of the servers are faulty, offline, or actively dishonest. An entry that the honest majority did not agree to simply never becomes part of the record.

No single operator can rewrite, reorder, or censor the record. Because no single server decides, no single operator can change history, put entries in a different order, or quietly drop one. That is the property the rest of DataVizor leans on: when a page tells you who belongs to your organization or which app is running, it is quoting a record that nobody could have edited on their own.

Who belongs to each organization, and in which role. Membership is the first thing the record holds: which accounts belong to each organization and the role each one has. Every permission check in the dashboard reads this, which is why membership can never disagree between two views of the same team — see the Organization section.

Projects, their budgets, and which apps are running. Projects, the budgets they carry, and the apps currently running are recorded too, along with which project each app belongs to. The Monitoring tab and the dashboard both read these entries rather than keeping their own copy.

Sealed secrets, volume locators, dataset fingerprints, network rosters. The other features each write their own kind of entry: the sealed envelope of a Quantum Safe secret (never its contents), the bucket-and-path locator of a volume, the fingerprint of a Marketplace dataset, and the roster of a Trust Network. Each section of this guide says exactly which of these it records.

Your data rows, and your credentials in the clear. Your data never goes into the record. In Collaborate, rows are split into masked pieces on your own machine; in the Marketplace, only a summary of a dataset is published. Credentials — storage keys, API keys, environment variables — are sealed in your browser first, and only the sealed envelope is recorded.

Your organization's name, logo, and member details. Your organization's name, logo, and member details are end-to-end encrypted before they are stored. The record holds the structure of your team — accounts and roles — but not the names attached to them; the Organization section explains the line between the two.

The traffic inside a Trust Network. A Trust Network's roster is recorded so its members can find each other, but the traffic between them is encrypted end to end inside the mesh and never touches the record at all.

What you see is what your teammates see. Because every page reads the same record, two teammates looking at the same organization see the same members, the same apps, and the same networks — there is no per-user cache to go stale and no sync step to wait for.

Nothing to reconcile, export, or resync between tools. There is also nothing to move between tools. Membership, budgets, and running apps are not exported from one system into another; they are entries that every part of the platform reads directly.

Stewarded by the Matter Foundation and its community. The ecosystem is stewarded by the Matter Foundation, which coordinates the network the record runs on, and by its community. The launch announcement below is the foundation's own description of it; matterdao.org is the community's home.

Members, roles, projects, and plan under one roof. Create an organization once and it holds everything your team runs here. Settings › Team manages people and their roles, Organization › Projects manages the projects your apps are grouped into, the plan you choose in Settings › Plan & billing decides which features are open to the whole team, and the Monitoring tab shows what all of it is doing right now.

Membership is recorded in the Matter Ecosystem. Who belongs to an organization, and in which role, is written into the Matter Ecosystem rather than into a database the dashboard owns. Any page that needs to know whether you are an Admin asks that shared record, which is why membership can never quietly disagree between two views of the same team.

One organization per account; its creator is Owner for life. An account can belong to exactly one organization, and the account that creates one is its Owner for the organization's whole life — ownership can never be transferred. If the Owner ever needs to leave, the only path is deleting the organization from Settings › General, which says so out loud.

Owner, Admin, Member, Viewer — each strictly narrower. There are four roles and each one is a strict subset of the one above it. An Owner has full control, including billing, settings, and deleting the organization. An Admin manages members, projects, and the lifecycle of running apps. A Member operates and deploys inside the projects they are assigned to. A Viewer reads what they are shown and changes nothing.

Every action in the dashboard checks your role. Every button, tab, and action in the dashboard checks the role of the account that is signed in before it does anything — the check is not decorative. A Member who opens Settings › General sees a read-only view; a Viewer who opens a project sees its apps without a Stop button. Least privilege is the default, and giving someone more is a role change in Settings › Team.

Join by email invite, shareable link, or company domain. New people arrive three ways. An email invite goes to one person and appears in their dashboard as a pending membership to accept. A shareable invite link does the same for anyone who follows it, with a role you set when you create it. Company-domain auto-join, when you enable it in Settings › General, lets anyone signing in with a matching email address join at the role you configured, without a per-person invite.

Nobody can remove themselves; escalation is a role change. Nobody can remove themselves or step down. An Owner or Admin removes members and changes roles; Owners cannot be managed at all, and the Owner's only exit is deleting the organization. This is deliberate: a team should never find its workspace empty because one person left in a hurry.

Projects group apps and carry their own budget. A project is the organization's unit of scope. It groups the apps that belong together, and it carries its own budget that those apps draw down as they run. Projects are managed in Organization › Projects — created, renamed, archived, and given a spending cap and deployers — and the dashboard groups each project's apps beside it.

Members and Viewers see only their assigned projects. Members and Viewers are assigned to projects, and they see only the projects they are assigned to. An Owner or Admin sees everything. This is how one organization can host several teams' work without any of them wading through the others' apps.

Monitoring lists every project's apps, with a Stop. The Monitoring tab lists every project's apps in one place — name, image, project, and status — and reads them fresh from the Matter Ecosystem each time you open or refresh it. Anything that should not be running has a Stop action in the same row.

Stopping needs your role plus deploy access on that project. Stopping an app takes more than a role. You also need to be an authorised deployer on that project's budget; otherwise the Stop button explains why and stays disabled. The extra check exists because stopping is billed and irreversible, so it is held to the same standard as launching.

Your organization's name, logo, and member details are end-to-end encrypted in the browser before they are stored. The keys stay with the organization: members who have been granted access can read those records, and nobody else — not the servers that hold the sealed copy, and not DataVizor.

What the Matter Ecosystem records legibly, on purpose, is the structure: which accounts belong to the organization and which role each holds. That structure is what every permission check reads, so it has to be public to the servers that enforce it. The names attached to those accounts are not part of it.

The practical reading: a teammate opening Settings › Team sees people; anyone else looking at the shared record sees account identifiers and roles, with no way to tell whose organization it is. If your threat model needs even the roster hidden, this is the limit to know about.

Plans are chosen per organization in Settings › Plan & billing and paid by card. Each plan unlocks a set of features — Collaborate, Storage, Networking, the ModelRouter — for every member at once, so a teammate never has to buy anything to use what the organization already has.

If an organization was created before its billing was set up, plan-gated features stay locked regardless of the plan you are paying for. The gated pages notice that state and offer a one-click fix that finishes the setup; nothing is lost, and the fix can be run more than once safely.

Each participant's data stays on their own machine. A Collaborate session is a joint computation, not a data exchange. Every participant keeps their rows exactly where they already live — a file, a database, a bucket — and connects them to a small agent running on their own computer. Nothing is uploaded to a shared workspace, and there is no moment when one party's records sit beside another's on any machine, including OpenMatter's.

Five independent servers compute over masked pieces. Before a value leaves your machine it is turned into masked pieces: random-looking fragments that reveal nothing on their own. A session always runs on five independent compute servers, the pieces are spread across them, and no single server can turn what it holds back into a row. The servers do their arithmetic directly on the pieces, and the only thing ever reassembled is the agreed output.

Everyone receives the same finished result. When the run finishes, every participant receives the same complete result — coefficients and fit scores for a training run, or per-row predictions for a scoring run. Each party then confirms the result it received, and the session can only be completed once every party has confirmed the same answer. The result is shared by design; what stays private is everything that produced it.

Train a built-in model, or score data with one. Sessions run built-in models only. Today that means Linear Regression and Logistic Regression, which fit a model over everyone's rows, and Random Forest and Neural Network scoring, where one party supplies a model and the others' rows are scored without either side seeing the other's input. Each model is a fixed arithmetic circuit built to run over masked pieces, which is why a session cannot execute arbitrary code.

Connect a file, database, or bucket to your agent. You connect data to the OMNI agent on your computer, not to the dashboard. A CSV file is read straight from disk; PostgreSQL, S3, BigQuery, Snowflake, and Redshift sources are pulled by the agent itself. The dashboard shows you the detected columns and their types so you can choose predictors and an outcome, while the rows themselves stay with the agent on your machine.

Raw rows never leave your machine. Raw rows never leave your machine. The agent reads them, profiles them, and masks them locally; nothing readable is sent to the dashboard, to another participant, to a compute server, or to OpenMatter. Even the check that decides which models your data is eligible for runs against a local profile, so choosing an analysis does not move your data anywhere.

Only masked pieces ever leave, never readable values. What leaves your machine are masked pieces — random-looking values that a server cannot turn back into your data on its own — sent over encrypted connections that the session brings up between your agent and the five servers. The one other thing that travels is the shape of your data, column names and types, which is described under Visibility and privacy below.

Every participant runs their own agent. Collaboration is symmetric. The host and every collaborator each run their own agent, and each agent masks its owner's rows locally, so nobody can hand their data to someone else's machine to be contributed on their behalf. The host walks the full wizard; a collaborator sees a single Supply Data step that points their own agent at their own source.

Download the OMNI agent once for Linux or macOS; it updates itself. The OMNI agent is one desktop download, installed once. Linux ships as an AppImage and as a Debian or Ubuntu .deb, each for Intel/AMD and ARM64; macOS ships as a disk image for Apple Silicon only; Windows is coming soon. The download panel on the walkthrough card always offers the newest release, with a one-line install hint beside each file. From version 1.13.0 the agent keeps itself up to date: about daily it checks for a newer release and offers it under Configuration → Software update, and nothing is installed until you click.

Start it — the dashboard finds it on your machine. Once the agent is running, the dashboard talks to it directly on your own computer — the browser tab and the agent are two programs on the same machine, and nothing is relayed through OpenMatter. There is no address to enter and no configuration file to edit; the page simply looks for a running agent and reports what it finds.

The status pill reads Agent Connected. The agent pill in the page header is your readiness check. It reads Agent Connected once the dashboard has reached the agent, and names the problem when it has not — for instance that nothing is running yet. Start or join a session only when it reads Agent Connected, because supplying data and receiving your result both go through the agent.

Keep it running while you're in a session. Keep the agent running for the whole session. It holds your connected source, maintains the encrypted connections to the compute servers, and delivers the result you confirm at the end; closing it mid-run interrupts your seat in the computation. The same agent and the same steps apply to the host and to every collaborator — there is no host-only mode.

Your rows, your values, and the credentials for any database or bucket source never leave your machine in readable form. The agent reads rows locally and masks them before anything goes out, and the credentials you type for a source are sealed in your browser before they are stored, so that only your own agent can unseal them — neither the dashboard nor OpenMatter can read them.

The shape of your data is shared on purpose. Column names and types, plus the predictor and outcome columns the host selects, are published so every participant can agree on a schema before a run, and a fingerprint of that column shape is recorded in the Matter Ecosystem so the host can check that everyone matched it. Sample values are stripped first. If a column name is itself sensitive, rename it before you connect the source.

The finished result is revealed to every participant and is itself a disclosure. Coefficients, fit scores, or predictions arrive in full for everyone, and each party's confirmation is recorded in the Matter Ecosystem. Do not run a model whose output you would not be comfortable handing to the other parties. Masked pieces on their own rebuild nothing; the result is the one thing the session exists to reveal.

Other participants can also see who has joined a session and whether each seat has marked itself Ready, and the results page shows which parties have confirmed. The Matter Ecosystem holds the session's structure — its host, its participants, the five servers assigned to it, the schema fingerprints, and the confirmations. Raw data, masked pieces, and intermediate values are never recorded there.

The host starts a session from the Collaborate page and chooses how many collaborators to invite — up to four, for five seats in all. Every session has a sixteen-character code and an invite link that carries it. Collaborators join by pasting the code or the link, or by opening the link, and land in the same lobby, where each seat marks itself Ready before the host starts the session.

The host walks four steps: Data Sources, where the agent is pointed at the data; Analysis, where a built-in model is chosen from those the connected data supports; Variables, where predictors, the outcome column, and parameters are set; and Run. A collaborator sees only Supply Data — connect a source through their own agent and confirm it matches the host's expected schema — followed by the same Run step.

Run advances on its own: the five compute servers are reserved, encrypted connections are brought up between every agent and every server, and then the computation runs with a live view of each server and each party. The results page shows the model's outputs and which parties have confirmed them, and offers a PDF report or a CSV download. When the host completes the session the servers are released, so export first.

Four models are available today. Linear Regression and Logistic Regression are training runs over everyone's rows, returning coefficients per predictor plus an intercept and fit scores — R² and RMSE, or accuracy and log-loss. Random Forest and Neural Network (MLP) are scoring runs: the host supplies a model, the participants supply rows, and every row comes back with a predicted class or score.

Each model exists as a fixed arithmetic circuit so it can run over masked pieces, and the compute servers check that the circuit they were reserved for is the one they are asked to run. That is why a session cannot be pointed at custom code, and why new models arrive as new circuits rather than as a scripting surface. The Analysis step only offers models your connected data is eligible for.

Collaborate is included on every plan. Plans are chosen per organization in Settings › Plan & billing, and every member of an entitled organization can start or join sessions without anything further to set up — beyond installing the agent on the machine that holds their data.

Draw a flow: request, numbered rules, an Otherwise, then models. A routing flow is a diagram on the Routing flow tab. A fixed Request node on the left feeds Rule nodes, and each Rule ends in a Model node that names an endpoint and a model. You add nodes from the palette, connect them by dragging, and press Save flow to make the gateway use it. The builder opens with a starter — two rules and an Otherwise — that you can save as-is or edit; until a flow is saved, the gateway routes nothing.

Rules read prompt text and length; first match wins, Otherwise last. Rules are tried top to bottom, and every rule card carries its number. A rule's checks read the prompt text — prompt contains “contract” — and its estimated length in tokens, combined with All or Any; the first rule whose checks match serves the request. The Otherwise rule always matches and is tried last. Plain-language rules are coming soon; a flow that already has one keeps working — the classifier model decides it at request time, and if it can't answer, the rule counts as not matched.

Each branch can name a second-choice model on the same endpoint. Every Model node can name a second-choice model. If the first model answers with a rate limit, a server error, a network failure, or no first byte within thirty seconds, the gateway retries once with the second choice on the same endpoint and records that it did. It never switches endpoints on its own, and other client errors — a bad request, an invalid key — are returned to the app as they came.

Test route previews the exact path a prompt will take. The Test route panel takes a sample prompt and a token estimate — roughly characters divided by four, or a number you type — and shows Request, then the rule, then model on endpoint, naming the rule that picked it — Rule 2 · Long prompt, or the Otherwise rule — with each skipped rule and why it was skipped. It runs the very same evaluator the gateway imports verbatim, so what you preview is what the gateway will do with the flow you are looking at.

Counts requests, tokens, latency, and fallbacks by endpoint and model. Once traffic flows, the gateway counts it: requests, prompt and completion tokens — marked estimated when the model service did not report them — average latency, and how often it fell back to a second-choice model. Every count is bucketed by endpoint and by the model that actually served the request, not the one first chosen, which is how the Overview can tell you which model is doing the work.

Apps point at one gateway, in the format they already speak. Today each app you deploy carries its own OpenAI key, its own Anthropic key, and its own hard-coded idea of which model to call. The ModelRouter replaces that with one small service, the gateway, that sits in front of all of them. Your apps keep speaking the wire format they already speak — OpenAI-style or Anthropic-style; the only change is that their base URL is your gateway's address (plus /v1 for OpenAI-style apps) instead of a model service's.

OpenAI-format and Anthropic-format tools both work — Claude Code included. Behind that one address the gateway can reach the hosted services offered on the Endpoints tab — OpenAI, Anthropic, and OpenRouter today — and any OpenAI-compatible server you run yourself, such as Ollama or vLLM. Anything registered on the Endpoints tab with a supported format is routable; the five lanes in the picture are the kinds of place a request can go, not a cap on how many you can add.

Change which model answers by editing rules, not redeploying. The gateway re-reads your saved routing flow on a short timer — about thirty seconds by default — rather than once at start-up. So changing which model answers a class of question is an edit and a Save on the Routing flow tab: nothing you deployed restarts, and no app's settings change. The app never knew which model it was talking to; it only knew the gateway's address.

Formats are translated when they differ; untranslatable features error. When a request's format and the routed endpoint's format match, the gateway forwards it untouched; when they differ — say Claude Code routed to a server you run — it translates the request and the response in both directions. A feature the other format cannot carry is refused with a clear error rather than silently dropped, and a Google-format endpoint still errors: the gateway has no client for it yet.

Paste each API key once; replace it in one place later. You paste an API key on the Endpoints tab exactly once, and after saving it appears only as a masked row. To change it, save the new key for the same endpoint: it is stored under the same label, and your gateway is re-granted access to it automatically as part of the save. Nothing that was deployed has to change, because nothing routed through the gateway ever contained the key.

Encrypted in your browser, stored sealed for your organization. The key is encrypted in your browser before it leaves the page, and what is stored for your organization is ciphertext that neither the dashboard nor the servers holding it can read on their own. It is stored for the organization, not for you personally, so every teammate's deployment can use the same key and nobody has to circulate it over chat.

Your gateway holds keys in memory only while serving. When your gateway needs a key it asks for it to be unsealed and keeps the result in its own memory for a few minutes at a time — five by default — so it is not unsealing on every request. Keys are never written to the gateway's disk, its container settings, or its logs, and they are gone the moment the gateway stops. If a refresh fails, the cached key is dropped rather than kept, so a revoked grant stops working promptly.

Apps routed through it get just a gateway token and address. An app routed through the gateway holds two things, and neither is a model-service key: a token that identifies it to your gateway, and the gateway's address. On the deploy page, Use ModelRouter writes exactly those two into the app's settings — the token where the API key would go, the address as the base URL. The separate Use key control does inject a stored key directly, for apps that cannot take a base URL; that is a choice you make per row.

When you paste an API key, your browser encrypts it before it leaves the page, and the stored copy is ciphertext. Unsealing it is a threshold operation — a quorum of a committee of independent nodes takes part — so no single server, not the ones holding the sealed copy and not DataVizor, can read the key on its own. After saving, the dashboard shows a key only as a masked row.

Who can unseal a key: Owners and Admins, who manage keys; Members, who may use a stored key or route an app through the gateway at deploy time; and your gateway's own service account, which is granted the endpoints list, the routing flow, and each stored key — nothing else. Viewers are granted nothing under the ModelRouter. The gateway is the one component that holds keys in the clear, in its own memory, so trust the machine running it as you trust the model services it calls.

A gateway set up from the ModelRouter page always gets an HTTPS hostname and a certificate, on every plan — the address is issued and renewed for you, so the gateway token and your prompts are never carried in the clear. On a network that offers no hostnames, setup is held rather than deploying a gateway that could only answer over plain HTTP.

Per-endpoint caps are granted to your gateway, which refuses requests past a cap until the period rolls over; it counts in its own memory since its last restart. Usage counters contain counts, token totals, latencies, and model names — never prompt text — and they live only in the gateway's memory; nothing about your traffic is recorded in the Matter Ecosystem. A classifier call sends the request text to the endpoint you chose, like any routed request.

A request arrives carrying the gateway token. The gateway checks it, loads the saved flow, endpoints and caps from a cache refreshed within seconds of a save, estimates the prompt's length, and tries the rules in canvas order with the Otherwise rule last; if a plain-language rule is in play it asks the classifier model once first. It checks the endpoint's cap, takes its key from memory, and forwards the request — translated when formats differ — with the model name replaced and the node's temperature and max tokens applied.

If the upstream answers with a rate limit or a server error, fails at the network level, or sends no first byte within thirty seconds, and the Model node names a second choice, the gateway retries once with that model on the same endpoint. Whatever response is chosen — streamed or not — is passed back to the app, translated when the formats differ, and one usage line is recorded against the endpoint and the model that actually served it.

Requests the flow cannot place get a structured error rather than a guess: no saved flow, no rule matched and there is no Otherwise, the chosen endpoint has reached its cap for the period, the winning endpoint speaks a format the gateway does not forward, or the endpoint expects a key none is stored for. Each error names its cause, so the fix is usually on the ModelRouter page; a refused translation names the field to change in your app.

Enforced: rules over prompt text and length, first-match-wins ordering with the Otherwise rule last, plain-language rules through the classifier model you pick, a Model node's temperature and max tokens (replacing the client's), per-endpoint caps (refused until the period rolls over), the single retry with a second-choice model on the same endpoint, key injection, forwarding in both formats, and translation between them. Every setting on this page takes effect once your gateway runs a release that knows it — the Overview says when it doesn't.

Not translatable: hosted tools, documents, audio and multi-choice requests cannot cross formats — such a request to an endpoint of the other format is refused with a named error; reply-tuning settings (JSON mode, reasoning effort, seed, penalties, thinking) are dropped, not refused. Not remembered: usage lives in the gateway's memory for 31 days and resets on restart, so a cap counts from the last restart. Not routed: until a flow is saved every request gets a no-flow error, so saving the starter flow is part of setup.

Claude Code speaks the Anthropic Messages format, so requests routed to Anthropic endpoints pass through untouched, and requests routed elsewhere are translated by the gateway.

1. 1. Point Claude Code at the gateway with two environment variables. ANTHROPIC_AUTH_TOKEN carries the token and outranks any saved login; the empty ANTHROPIC_API_KEY only silences the startup warning when a real key is also exported.

   shell

   Copy

   export ANTHROPIC_BASE_URL="https://<your-gateway>"
   export ANTHROPIC_AUTH_TOKEN="om-gw-v1-<your gateway token>"
   export ANTHROPIC_API_KEY=""

2. 2. Or persist it for every project in ~/.claude/settings.json.

   ~/.claude/settings.json

   Copy

   {
     "env": {
       "ANTHROPIC_BASE_URL": "https://<your-gateway>",
       "ANTHROPIC_AUTH_TOKEN": "om-gw-v1-<your gateway token>",
       "ANTHROPIC_API_KEY": ""
     }
   }

3. 3. Optional: name the routing flow explicitly with ANTHROPIC_MODEL. Claude Code's /model picker only lists ids containing “claude” or “anthropic”, so openmatter/auto never appears there — setting it by name is how you pick it. Discovery is what makes your flow's Claude-named models show up in that picker.

   shell

   Copy

   export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1
   export ANTHROPIC_MODEL="openmatter/auto"

OpenCode reaches the gateway through one dedicated entry of its own, in the OpenAI format. The gateway serves that natively from OpenAI-compatible endpoints and by translation from Anthropic ones.

1. 1. Add the gateway to opencode.json as its own entry, with the token in the same block — values here outrank both environment variables and a key saved earlier with /connect, so a token anywhere else would lose. Keep the /v1: OpenCode appends the route itself. The models block is what puts the routing flow in the model picker.

   opencode.json

   Copy

   {
     "provider": {
       "om-gateway": {
         "npm": "@ai-sdk/openai-compatible",
         "name": "Org gateway",
         "options": {
           "baseURL": "https://<your-gateway>/v1",
           "apiKey": "om-gw-v1-<your gateway token>"
         },
         "models": {
           "openmatter/auto": {
             "name": "openmatter/auto"
           }
         }
       }
     }
   }

Cursor speaks only the OpenAI chat format, and only its OpenAI key field can override the base URL. The gateway serves it natively from OpenAI-compatible endpoints and by translation from Anthropic ones.

1. 1. Open Cursor Settings → Models → API Keys, paste the gateway token into the OpenAI API Key field, and click Save.

2. 2. Turn on “Override OpenAI Base URL” and set it to the gateway address plus /v1, with no trailing slash. There is no Verify button in current Cursor — the key is used as soon as it is saved.

   shell

   Copy

   https://<your-gateway>/v1

3. 3. Under Models, use “+ Add model” to add openmatter/auto; a name that matches a Cursor built-in is rejected. Under the default auto-route mode the name you pick is only a label — the flow chooses the model. If you switch the flow to honour named models, add the names GET /v1/models lists instead.

   shell

   Copy

   openmatter/auto

Copilot Chat's Custom Endpoint feature (VS Code 1.122 or later) speaks either format. Point it at the gateway's messages route (or the chat route) and it behaves like any other model in the picker.

1. 1. In the Chat view, open Manage Language Models (gear icon) → Add Models → Custom Endpoint. Enter a group name, a display name, the gateway token as the API key, and pick Messages (or Chat Completions) as the API type.

2. 2. VS Code opens chatLanguageModels.json with the key already stored: the apiKey line reads ${input:chat.lm.secret.…}, a reference into VS Code's secret storage — not a prompt. Keep that line exactly as VS Code wrote it and edit only the models array.

   chatLanguageModels.json

   Copy

   [
     {
       "name": "Org gateway",
       "vendor": "customendpoint",
       "apiKey": "${input:chat.lm.secret.<keep the value VS Code wrote>}",
       "apiType": "messages",
       "models": [
         {
           "id": "openmatter/auto",
           "name": "openmatter/auto",
           "url": "https://<your-gateway>/v1/messages",
           "toolCalling": true,
           "vision": true,
           "maxInputTokens": 200000,
           "maxOutputTokens": 64000
         }
       ]
     }
   ]

3. 3. Prefer the OpenAI shape? Change these two fields — apiType to "chat-completions" and each model's url to the chat route:

   JSON

   Copy

   {
     "apiType": "chat-completions",
     "url": "https://<your-gateway>/v1/chat/completions"
   }

Set Cline up in its settings pane: pick “OpenAI Compatible” or “Anthropic” with a custom base URL. Either the bare gateway address or the address plus /v1 works — Cline normalises both.

1. 1. In Cline's settings, pick “OpenAI Compatible” in the API dropdown, then fill the three fields:

   shell

   Copy

   Base URL   https://<your-gateway>/v1
   API Key    om-gw-v1-<your gateway token>
   Model ID   openmatter/auto

2. 2. Or choose “Anthropic”, tick “Use custom base URL”, and give it the gateway address with the token as the key. This path's model dropdown lists Claude names only — fine under auto-route, but to pick your flow's own model names use the OpenAI Compatible path.

   shell

   Copy

   https://<your-gateway>

Zed declares custom model services in settings.json — an openai_compatible entry (address + /v1) or an anthropic_compatible one (bare address). Enter the key in the agent panel, never in the file.

1. 1. Add the gateway under language_models in settings.json. Deliberately no token here — Zed's own rule is that keys never live in settings.json.

   settings.json

   Copy

   {
     "language_models": {
       "openai_compatible": {
         "Org gateway": {
           "api_url": "https://<your-gateway>/v1",
           "available_models": [
             {
               "name": "openmatter/auto",
               "display_name": "openmatter/auto",
               "max_tokens": 128000
             }
           ]
         }
       }
     }
   }

2. 2. Run “agent: open settings”, find “Org gateway”, and paste the token as its API key — or export ORG_GATEWAY_API_KEY before launching Zed.

Aider reaches any OpenAI-compatible address through two environment variables and an openai/ model prefix.

1. 1. Export the pair and launch with the prefixed model name.

   shell

   Copy

   export OPENAI_API_BASE="https://<your-gateway>/v1"
   export OPENAI_API_KEY="om-gw-v1-<your gateway token>"
   aider --model openai/openmatter/auto

Both official SDKs need one setting, the base URL. The OpenAI SDK takes the address plus /v1; the Anthropic SDK takes the bare address (it appends /v1/messages itself).

1. 1. OpenAI SDK:

   Python

   Copy

   from openai import OpenAI
   client = OpenAI(base_url="https://<your-gateway>/v1", api_key="om-gw-v1-<your gateway token>")
   reply = client.chat.completions.create(
       model="openmatter/auto",
       max_tokens=64,
       messages=[{"role": "user", "content": "ping"}],
   )

2. 2. OpenAI SDK, Responses API — same client, served by translation:

   Python

   Copy

   from openai import OpenAI
   client = OpenAI(base_url="https://<your-gateway>/v1", api_key="om-gw-v1-<your gateway token>")
   reply = client.responses.create(model="openmatter/auto", input="ping", max_output_tokens=64)
   print(reply.output_text)

3. 3. Anthropic SDK:

   Python

   Copy

   import anthropic
   client = anthropic.Anthropic(base_url="https://<your-gateway>", api_key="om-gw-v1-<your gateway token>")
   reply = client.messages.create(
       model="openmatter/auto",
       max_tokens=64,
       messages=[{"role": "user", "content": "ping"}],
   )

Codex speaks only the OpenAI Responses format (its chat option was removed in version 0.95, February 2026). The gateway serves that route by translation on every endpoint — OpenAI-compatible ones directly, Anthropic ones through the chat format.

1. 1. Describe the gateway as a model service in ~/.codex/config.toml. base_url is the gateway address plus /v1 — Codex appends /responses itself. env_key names the variable Codex reads the token from, so the file holds no secret. web_search = "disabled" matters: Codex otherwise offers its hosted web-search tool on every request, which no routed endpoint runs, so the gateway would refuse the request.

   ~/.codex/config.toml

   Copy

   model_provider = "om-gateway"
   model = "openmatter/auto"
   web_search = "disabled"
   
   [model_providers.om-gateway]
   name = "Org gateway"
   base_url = "https://<your-gateway>/v1"
   env_key = "OPENMATTER_GATEWAY_TOKEN"
   wire_api = "responses"

2. 2. Export the token under that name, then start Codex.

   shell

   Copy

   export OPENMATTER_GATEWAY_TOKEN="om-gw-v1-<your gateway token>"
   codex

A volume is a pointer: bucket, path, and access keys. A volume is a registered pointer with three parts: the bucket (or container, Space, or CID), the object key or prefix inside it, and the credentials that reach it. The bucket and path become a locator such as s3://bucket/key, gs://bucket/key, az://container/key, or ipfs://cid. You can also give the volume a label, a declared size for materialized volumes, and an optional SHA-256 content root — the only integrity check on offer.

Nothing is uploaded; your data stays where it already lives. This page never moves data. You put the object — or the tree, for a live mount — into your bucket with the tools you already use; the dashboard has no upload path and keeps no copy of the contents. Your apps read the data where it already lives. Register the pointer whenever you like: a volume simply waits in Preparing until you say the data is in place.

The bucket stays yours, with the storage source you already use. The bucket stays under your own account, with the storage source you already use — Amazon S3, Google Cloud Storage, Azure Blob Storage, IPFS, Cloudflare R2, Backblaze B2, Wasabi, MinIO, or DigitalOcean Spaces. Five of those are S3-compatible and differ only by the endpoint you enter. Access is exactly what your credentials allow; the dashboard adds no permissions of its own.

Register once, attach to any app, Mark Ready when in place. A new volume starts in Preparing. Once the object is actually in the bucket, click Mark Ready — that click is your assertion that the data is in place, not a check the dashboard performs. If you supplied a content root, integrity is verified when the volume is materialized for an app. Every Ready volume then appears in the deploy page's volume picker, and any of your apps can attach it.

Access keys are threshold-encrypted in the page — Quantum Safe. Access keys are the one secret in this flow. Before the Add Volume form is submitted, whatever you typed — an S3 key pair, a Google service-account JSON, an Azure access key or SAS token, an IPFS auth token — is threshold-encrypted right in your browser into a sealed envelope: a capsule, a proof, and the ciphertext. The Quantum Safe badge beside the credential fields opens a short walkthrough of how that seal works.

The dashboard can encrypt a key but never read it back. The dashboard is encrypt-only. It holds nothing that could open the envelope, so it cannot show a key back to you, and the raw key is never saved in the clear. The envelope is bound to a fixed tag that marks it as storage credentials, so it can only ever be opened as one. If you need to see or change a key, you retire the volume and register a fresh one.

Granted only to the machine running your app, once it's scheduled. When an app that uses the volume is scheduled, the sealed secret is granted to the machine that will run it, and that machine unseals the credentials to fetch or mount your data. The grant is revoked when the app is torn down. Your cloud keys exist in the clear only where the work runs — never in the dashboard, and never in the shared record.

Public buckets can be registered with no credentials at all. For Amazon S3, Google Cloud Storage, and IPFS you can tick Public / anonymous backend and register with no credentials at all: no secret is written, and a live mount registered this way is read-only. The other sources always need credentials — Azure, for one, cannot be reached anonymously because the account name lives only in the credentials. Write-capable keys give a writable mount; read-only keys give a read-only mount.

Materialized: fetched and unpacked once, before your app starts. A materialized blob is the classic dataset drop. For each app that uses it, the object is fetched from your bucket, verified against the content root if you supplied one, and unpacked at the mount path before your code starts. It is the mode that supports a declared size, an integrity commitment, and scheduled snapshots. The source object is treated as immutable: changes your app makes to its copy are not written back to it.

Live mount: the bucket appears as a folder; writes upload on close. A live cloud mount never copies the object. The bucket, or a prefix of it, is mounted into the container as a folder: reads stream from the bucket on demand, and writes are uploaded when a file is closed, so briefly a file can exist on the machine but not yet in the bucket. Because the tree is mutable, a live mount cannot carry a content root and has no declared size. Only S3, Google Cloud Storage, and Azure sources can be live-mounted; IPFS cannot.

Live mounts suit large datasets, not databases or lock-heavy workloads. Live mounts behave like any network filesystem: excellent for large datasets and shared trees, poor for databases and lock-heavy workloads, because every write travels back to the bucket after the file closes. They cannot have snapshots either — the data already lives in your bucket. The delivery mode is chosen when you register the volume and cannot be changed afterwards.

An empty prefix mounts the whole bucket. For a live mount the object key becomes an optional prefix. Leave it empty and the whole bucket appears at the mount path; set it to expose only a subtree such as datasets/v1. Live mounts depend on the version of the Matter Ecosystem you are connected to: where they are not yet available, the option is disabled with a note saying so.

Every Ready volume appears in the deploy page's volume picker. When you launch an app, the deploy page's volume picker lists every volume of yours that is Ready — None (ephemeral) is the default, and live mounts are marked as such. A Preparing or Retired volume is not offered. A running app can also attach, detach, or remount volumes later from Manage Volumes in its row on the dashboard, then Save & Update to apply the change.

Pick a mount path; tick Mount read-only when needed. The mount path you set in the deploy form is where the volume is materialized or mounted inside the container. Tick Mount read-only when the workload should never write — a training set, a reference corpus, a tree several apps share. It applies on top of whatever the credentials allow: read-only keys, or a public bucket on a live mount, give a read-only mount regardless of the checkbox.

Materialized volumes can snapshot every 6 hours, daily, or weekly. Backups run on the machine hosting your app, and only materialized volumes can have them. From the volume's card choose Enable backups, pick a destination — any source except IPFS — with a bucket and optional prefix, add write credentials for it (sealed exactly like read credentials), then a frequency of every 6 hours, daily, or weekly. Snapshots are taken while the volume is attached to a running app; a detached volume takes none.

Keep up to 32 snapshots; restore any from the card. Retention is 1 to 32 snapshots; the oldest is pruned when the limit is reached. Manage backups on the card opens the same modal, where you can change the frequency or retention, disable backups, or pick a snapshot from the list and click Restore. Restore repoints the volume at that snapshot and returns it to Ready straight away. To change the destination, disable backups and enable them again. Where your version of the Matter Ecosystem lacks backups, the controls are hidden.

Only the credentials are encrypted. Before registration is submitted, your access keys are threshold-encrypted in the page under the Quantum Safe seal, producing a capsule, a proof, and the ciphertext. That envelope is held in the Matter Ecosystem as the volume's storage secret. The dashboard is encrypt-only: it holds nothing that could open the envelope, never shows a key back, and never saves a raw key in the clear. The same applies to the write credentials of a backup destination.

The locator is not a secret. The bucket name and object path — s3://bucket/key and the like — together with the volume's label, declared size, content root, status, and backup schedule and destination, are readable by anyone in the Matter Ecosystem. Your key is protected; its address is not. Choose bucket and path names accordingly.

In this version the bucket's contents are stored as-is: Encrypted Storage encrypts the credentials, not the data. If the data itself must be confidential, encrypt it before you put it in the bucket, or keep it in a private bucket whose keys you seal here.

A volume is owned by the account that registered it, not by your organization. Teammates do not see your volumes on their Storage tab or in their deploy picker, and every action — Mark Ready, Retire, Delete, enabling or restoring backups — is checked against the owning account, not merely hidden in the dashboard.

The only way a volume's data reaches anyone else is by attaching it to an app: whoever can reach that app can read what it mounted. Nothing else about a volume is shared, apart from the readable record described above.

A volume starts in Preparing when you register it. Click Mark Ready once the object — or the tree, for a live mount — is actually in your bucket; that is your assertion that the data is in place. Ready volumes are what the deploy page offers. Restoring a snapshot repoints the volume and returns it to Ready at once, with no fresh Mark Ready needed.

Retire a volume when you no longer want it attached or changed: it stays listed but can no longer be attached or modified. Delete is offered only for a Retired volume that no running app still references; deleting removes the volume record and its snapshot history, and scrubs the sealed credential secrets it owned.

There is no in-place credential change in this dashboard. To rotate or replace access keys, retire the volume and register a new one with the fresh keys. The delivery mode — materialized or live mount — is likewise fixed at registration. Live mounts, backups, and delete each depend on the version of the Matter Ecosystem you are connected to; where one is not available, its control is hidden or disabled.

Each dataset is described, not delivered. A Marketplace listing is a description of a dataset, not the dataset. When an owner registers data, what gets listed is a summary document: what the columns are, how many rows there are, what range each numeric column spans, and who collected it and when. That is enough to decide whether the data fits a question you want to answer, which is the only decision the catalog is built to support.

Schema, row count, value ranges, and source notes. Each listing carries the same fields, so datasets compare like for like: a label and description, the author and the source the data came from, an optional collection date, citations, the row count, and one line per column with its name, type, unit where there is one, and the smallest and largest value seen. The detail page lays these out as a schema table and a statistics panel.

Rows stay on the owner's machine. The rows are read on the owner's machine by the OMNI agent, which computes the summary locally; the summary is what gets uploaded, and the rows are not. DataVizor never receives them, and nothing on a dataset page fetches them. A listing is a self-custody record by construction — the owner keeps the data and publishes only its shape.

Nothing is bought or sold; you judge, then collaborate. There is no price on a listing and no checkout, because nothing changes hands. The catalog exists to answer what data exists and what shape it is in; using a dataset means opening a Secure Data Collaboration session over it, where a model runs across the data without anyone handing it over. Browsing needs no account — signing in is for registering, liking, and collaborating.

Publishing records a BLAKE3 fingerprint in the Matter Ecosystem. Publishing a dataset records two fingerprints in the Matter Ecosystem: a BLAKE3 digest of the exact bytes of the summary document, and a digest of the column names and types. The summary itself is stored elsewhere, in a store that only accepts a document whose bytes hash to the recorded digest. The record and the document are separate things, and the fingerprint is what ties them together.

Each load re-hashes the served summary and compares. Whenever a dataset page opens, it fetches the summary as raw text, hashes that text itself, and compares the result with the digest in the record — before it renders a single field from the document. A cached copy is never trusted on its own. The check is quick and runs on every load, so what you read is what the owner committed to when they published.

A mismatch hides the summary and says so. If the served bytes hash to anything other than the recorded digest, the page hides the summary and shows a warning that says the summary failed verification. What remains is the record itself — the label, the owner, the status, the version, and the two fingerprints — and the page says those are the only fields to trust. A summary that cannot be verified is shown as missing rather than as wrong.

Six steps: agent, source, schema, describe, owner, publish. Registering runs through six steps, each with its own address in the wizard so a half-finished link still lands on the right one: connect the agent, choose a source, review the schema, describe the dataset, choose the owner, and publish. Each step gates the next — you cannot describe a dataset that has not been ingested, or publish one whose schema you have not confirmed.

Ingest from CSV, PostgreSQL, S3, Redshift, BigQuery, or Snowflake. The source step offers six ways in: a CSV uploaded from this machine, a PostgreSQL table, a CSV or Parquet object in an S3 bucket, a Redshift table, a BigQuery table, or a Snowflake table. Whichever you pick, the agent on your machine does the reading, and the ingest has to finish with at least fourteen rows and one column before the wizard lets you continue.

The local OMNI agent computes the summary; rows stop there. The OMNI agent is a small program you run on your own machine; the wizard's first step checks that it is reachable and recent enough. It reads your rows, computes the row count and the per-column ranges, and hands the wizard a summary. The rows go no further than the agent — the summary is the only thing that travels from your machine.

You confirm the columns; publishing records them in the Matter Ecosystem. The schema step lists every column the listing will carry and asks you to tick a box before you can go on; nothing is listed that you have not seen there. Publishing then registers the dataset in the Matter Ecosystem as a draft, uploads the summary, fetches it back and checks its fingerprint, and only then marks it published. If any stage fails, the wizard keeps your work and offers a retry.

Likes are one per account, with a short cooldown. A like is an action you sign from your own account, and the record keeps at most one per account per dataset, so a second like from the same account is an unlike, not a double count. Both directions share a cooldown of ten blocks — about a minute at the network's six-second cadence — which is enough to keep a script from flipping a heart on and off to game the count. Only published datasets can be liked.

Owners can set an identity and request a registrar's judgement. An owner who wants a badge opens Get verified from their dataset page. The first step sets an identity — a display name — from their account; the second asks a registrar to judge it; the third is waiting, because judgement arrives on its own schedule and the badge updates when it lands. The dashboard marks which registrars it trusts, and only a judgement from one of those turns the badge on.

Verified vouches for the owner, not the data. A verified badge means a trusted registrar has judged the owner's identity to be known-good or reasonable. It says who is behind the listing; it says nothing about whether the data is accurate, complete, or fit for your purpose — nobody has looked at the rows, because the rows never left the owner. The badge shows on every dataset that account owns; in this version it applies to personally owned datasets, not project-owned ones.

“Use in collaboration” opens a Secure Data Collaboration session. Every dataset page has a Use in collaboration button. It opens the Collaborate wizard with this dataset already linked, so you start a Secure Data Collaboration session from the listing instead of from a blank form. Collaborate has to be part of your organization's plan, and you need to be signed in — an anonymous click simply asks you to sign in first.

The dataset's columns pre-fill the session's expected schema. The link carries the dataset's columns into the session as its expected schema: the names and types every participant's data has to match. That schema is the same thing the record's second fingerprint was computed over, so the wizard can check that the summary it was handed still agrees with what the owner registered, and notice one that no longer matches.

A model runs across data no participant reveals. Inside the session, each participant's rows stay on their own machine with their own OMNI agent; what leaves are masked pieces that no single node can read, and a model is trained or scored across them. Because the rows never left the owner's machine, the owner has to take part for their data to be in the session at all — their agent supplies it, masked, like any other participant's.

Answers move; data doesn't. What comes back is the finished result, and every participant receives the same one. No participant ends the session holding another's rows, no copy of the dataset was made along the way, and the listing in the catalog is exactly as undisclosed afterwards as it was before. That is the whole point of describing data instead of delivering it.

A listing is readable by anyone, signed in or not. Its summary carries the description, author, source, optional collection date, citations, row count, and one line per column: name, type, unit, whether it allows empty values, and the smallest and largest value seen. Sample values are never part of it — the summary format has no field for them, and the schema step says so before you confirm.

The record in the Matter Ecosystem is open as well: the label, the owner's account (or the organization and project, for a project-owned dataset), the status, the version, the two fingerprints, and the like count. Likes are recorded per account, so a like is not anonymous. An owner's display name, once set, is stored in the open too.

The rows never leave the owner's machine, so there is nothing to protect on the server side — the protection is that they were never uploaded. The one thing to weigh before publishing is the ranges: for a column with few rows, the smallest and largest value can reveal an individual value, and the schema step is the moment to decide whether that is acceptable.

A dataset is registered as a draft and becomes published only after its summary has been uploaded and verified. The catalog lists published datasets by default; drafts, retired, and delisted datasets are reachable through the status filter, and show only their record fields. If the upload stalls, a Metadata upload pending banner on the wizard and on the owner's detail page offers a retry that resumes exactly where it stopped.

Two further states exist. Retired is the owner's withdrawal, and it is final apart from deleting the record. Delisted is a moderation takedown, and only the network's root authority can restore a delisted dataset to published. Neither state removes the record, so a link to a retired or delisted dataset still resolves to its label, owner, and fingerprints.

The register wizard needs the OMNI agent running on the machine you are using, on a build recent enough to ingest sources and compute statistics; the first step checks both and will not advance otherwise. An ingest must produce at least fourteen rows and at least one column. The label is limited to 96 bytes, and the description and author are required; citations are optional and never block publishing.

Likes and Use in collaboration are shown to everyone but act only when signed in — an anonymous click opens sign-in. Only published datasets can be liked. Get verified appears only to the owner, only where the connected network supports identities, and only for personally owned datasets; project-owned datasets show their organization and project instead of a badge.

Apps and laptops share one encrypted 10.1.x.x address space. Every network you create here is a WireGuard overlay: one block of 10.1 addresses, 10.1.<subnet>.0/24, shared by your deployed apps and your own devices. Each member gets its own address in that block, and everything they say to each other travels inside the WireGuard tunnel, encrypted end to end between the two members involved. Services that were never exposed to the internet can still reach each other by those addresses.

Members reach each other directly, wherever they run. Members talk to each other directly rather than through a relay, so it makes no difference where they physically run. Apps join as Peers, which publish a reachable endpoint; laptops join as Clients, which sit behind NAT and do not listen. A laptop reaches every app and apps reach each other, but two laptops on the same network are not written into each other's configs and do not dial one another.

The Matter Ecosystem tracks membership; it never carries traffic. The Matter Ecosystem's only job is coordination. It records the network, its seat count, its open invitations, and each member's WireGuard public key, so every member can build the same picture of who is in and how to reach them. No packet of your traffic ever passes through it, or through this dashboard; the dashboard only reads the roster and signs the changes you ask for.

Name it and pick 2–32 seats, apps and laptops together. Create a Network asks for a name — letters, numbers, hyphen, or underscore, because it becomes the filename of the config you download later — and a maximum number of members from two to thirty-two. Apps and laptops count against the same cap, so a network for three services and two engineers needs at least five seats. The dashboard offers no way to raise the cap afterwards, so leave some headroom.

Two signatures: register the network, then connect this device. Creating signs two transactions in sequence. Step one registers the network in the Matter Ecosystem. Step two connects this device as a Client, using a WireGuard key supplied by the local OMNI agent, so you are on the network the moment it exists. If the agent is not running, step two is skipped with a warning; the network is still created, and you connect this device afterwards from its Connect This Device tab.

Invites go to an account address with a chosen deadline. Invite Account, on the network's Invitations tab, takes a teammate's account address — the 5… address they sign in with — and a deadline of one day, one week (the default), or thirty days. The invitation is recorded with that deadline and appears in the teammate's own Networking tab. While it is open, the owner can revoke it from the same Invitations tab.

Invitees accept or decline from their own Networking tab. Your teammate sees the pending invite at the top of their own Networking tab, with Accept and Decline beside it. Accept also connects their device in the same signature when their local agent is reachable, using the agent's key; if it is not, the acceptance still goes through and they connect a device afterwards from the network's detail view. Decline simply closes the invitation.

Pick one of your running apps and sign once. Add App as Peer, on the Members tab and offered to the network's owner, lists the running apps you own that are not already on this network. Choose one and sign a single authorisation; that is the only action you take. Apps that are queued, stopped, or finished are not offered, because a Peer has to be live to publish an endpoint that other members can reach.

The app joins with its own key — you never handle it. Your signature authorises the app; it does not carry a key. The machine running your app sees the authorisation and registers the app's own WireGuard identity and reachable endpoint. You never see, download, or paste that key, and the dashboard never holds it — which is also why an app can only be added by the account that deployed it.

Until it connects, it shows in a pending list. Between your signature and the app's own join, the app appears under Pending peer apps on the Members tab. That state is real rather than decorative: it reflects an authorisation that has not been fulfilled yet, and the roster moves the app into the member list the moment its join lands. If it lingers, the owner can revoke the pending authorisation from the same list.

Generate a WireGuard keypair here, or paste one you already have. The Connect This Device tab offers two paths. Generate Keys creates a WireGuard keypair right in this page and shows you both halves, with the secret half hidden behind a Reveal button and a copy button beside each. Use Existing Key accepts a 44-character public key you made yourself with wg genkey and wg pubkey, so the secret half never enters the browser at all.

Secret half stays on this device; only the public half is registered. Save key & get config registers only the public half, as a Client member of the network. The secret half is never sent anywhere and never written to disk or browser storage; it exists only on this page until you close it, so copy it into your config before you leave. If you lose it, that device has to be removed from the network and connected again with a fresh keypair.

Download a ready-made .conf and run wg-quick up. You are then shown your assigned address, 10.1.<subnet>.<slot>, and a complete <network>.conf with an Interface block and one Peer block per app, ready to download or copy and bring up with sudo wg-quick up. If you open the tab again later, the same config is shown with a PrivateKey placeholder for you to fill in from your own copy.

Every peer app is then one 10.1 address away. The generated config lists only Peer apps. Laptops are Clients: they do not listen, so they are not written into each other's configs and cannot be dialled directly. Once the tunnel is up, each app on the network is reachable at its own 10.1 address, and a keepalive every 25 seconds holds the tunnel open from behind NAT.

Every member listed: apps as Peers, laptops as Clients. Open any network card and the Members tab lists every member with its kind — Peer for an app, Client for a laptop — its 10.1 address, and what it is: app #<id> or account <address>. The card itself shows the network's status (Provisioning, Ready, or Tearing down), its subnet, and how many of its seats are taken.

Open invites and pending apps sit alongside. The same view keeps the in-between states visible. The Invitations tab lists every invite still open, with the deadline it was given; the Members tab shows Pending peer apps — apps you have authorised whose own join has not landed yet. Neither is hidden while it waits, and each can be revoked by the owner from where it is listed.

Updates as the Matter Ecosystem confirms each change. The list is driven by live events from the Matter Ecosystem: the dashboard listens for every change to a network and re-reads the roster as soon as one is confirmed, so a member joining, an invite being accepted, or an app connecting appears without a page reload. There is no dashboard-only state — a row on this screen is a row in the shared record.

Owners remove members, revoke invites, or delete the network. Owners manage the roster: Remove a member, Revoke a live invite or a pending app, and Delete Network, with a confirmation that spells out what would be evicted when the network still has members or invites. Networks created automatically for a project are the exception — they show a Project network badge and are removed only by deleting the project.

The privacy of a network is about the traffic, not the coordination. Everything your apps and laptop say to each other travels inside the WireGuard tunnel, encrypted end to end between the two members involved; neither this dashboard nor the Matter Ecosystem can read it, and neither ever relays it.

The coordination is shared on purpose. The network's name, owner, and seat count, its roster, every open invitation including the invited account address, and each member's WireGuard public key — plus, for apps, the endpoint it can be reached at — are recorded in the Matter Ecosystem, where anyone can read them. A public key cannot decrypt anything; it only lets members recognise each other. But the fact that a given account and a given app share a network is not hidden.

Secret keys are the one thing that never leaves your side. Your laptop's secret half exists only in the page that generated it, or on your own machine if you made it with wg genkey; an app's key is created and held by the machine running the app. Nothing in the dashboard, and nothing in the Matter Ecosystem, holds a secret half for anyone.

Ownership is per network and belongs to the account that created it. Only the owner sees Add App, Remove on a member, Revoke on a pending app or a live invite, Invite Account, and Delete Network. Every member can open the network, read its roster, and use Connect This Device. An invitee can accept or decline only their own invitation.

Networks created automatically for a project appear under Networks you've joined for the project's members, with a Project network badge. They cannot be deleted from this page; delete the project and its network goes with it.

You list the hosts an agent may reach; everything else is refused. A policy's allowed-hosts list is the whole of what an agent may reach. Anything not on it is stopped at the boundary, whatever the agent tries and whatever it was persuaded to try — a prompt injection that talks an agent into contacting somewhere else gets no further than a request that is refused. The list is a positive one, so a host you have never thought about is a host that is already refused.

The list is the whole permission — nothing is allowed by default. Nothing is allowed by default, which is why a brand-new policy that lists nothing reaches nothing at all. That is a valid and rarely intended state, so the editor says so plainly rather than letting an empty list read as an oversight. The safe direction is the one you get by writing nothing, and widening it is always a deliberate act you can point at afterwards.

A refused attempt is recorded too, so you see what it tried. A refusal is not silent. The attempt produces its own entry alongside the allowed ones, so 'did it ever try to reach somewhere it should not' is a question with an answer rather than a matter of trust. What the entry publishes is deliberately thin — that a decision was made, and what it was — so the record can be shared without disclosing the contents of the request that produced it.

Nothing about your app changes: the boundary sits around it. Your application is not modified, rebuilt or repackaged to be guarded. You deploy the same image you would have deployed anyway, and the boundary is placed around it. That means turning the boundary on is a per-deployment choice rather than a commitment to a different way of building, and an agent that runs unguarded today can run guarded tomorrow with no change to its code.

A handled credential is swapped in at the boundary, never given out. A credential you mark as handled is never given to the agent. The agent receives a stand-in value that is generated fresh each time it starts, and the real value is substituted at the boundary on its way out. The agent works exactly as it would have, and never holds anything worth stealing — so a leak from the agent, however it happens, discloses a stand-in rather than your key.

Each one is limited to the hosts you scope it to. Each handled credential is limited to the hosts you scope it to, and to hosts that are inspected. Both halves matter: an unscoped credential would be disclosed to whichever allowed host the agent pointed it at, and a host that is allowed but not inspected is never opened, so nothing can be substituted into it. A policy that gets either wrong is refused when the agent starts rather than quietly doing something narrower.

The agent holds a stand-in, so a leak from it discloses nothing. Because the agent holds only a stand-in, the usual failure modes stop being interesting. A credential printed into a log, echoed back in a reply, or included in a request to somewhere it was not scoped to is a stand-in in every case. That is a different guarantee from being careful with your keys: it does not depend on the agent, or on the model driving it, behaving well.

Settings you do not list are dropped before the agent starts. Plain settings work the other way round and are just as deliberate. A name you do not list is dropped before the agent starts, silently, which means forgetting to declare something withholds it rather than handing it over. The safe direction costs you a feature that does not turn on; the other direction would have cost you a credential, so the editor names exactly which settings are being withheld.

A policy belongs to your organization, not to one agent. A policy belongs to your organization rather than to one agent. It is a document with a name, stored for the organization and readable and editable by any owner or admin — not only by whoever first wrote it. Two agents that should enforce the same boundary can therefore share one policy, instead of being two hand-written documents that drift apart the first time only one of them is corrected.

Start from a ready-made one, or write your own. OpenMatter ships four ready-made policies covering the common shapes, from one that reaches nothing at all to one that allows only your own model gateway. They are read-only on purpose: an agent attached to one of them means the same thing this year as it did last year. When you want a variation, duplicate one — the copy is yours, and editing it never changes the original or anything else using it.

Attach the same policy to as many agents as you like. The same policy can be attached to as many agents as you like, and each attachment is sealed for that agent alone. Nothing is shared between them beyond the document itself, so removing one agent affects no other, and an agent keeps working exactly as it was even if you later delete the policy from your library. The list of policies shows how many agents each is attached to.

Change it on a running agent without deploying again. Changing a policy on a running agent does not require deploying it again. Attach a different one and the agent picks it up where it runs, usually within about half a minute. Some parts of a policy are only read when an agent starts, so a change touching those waits for a restart — the agent itself says which, and the dashboard offers the restart rather than performing one you did not ask for.

Each allowed or refused action produces its own entry. Every action the boundary decides on produces its own entry, whether it was allowed or refused. The entry says when the decision happened, what kind of action it was and which way it went, and carries a proof that the decision followed the policy in force. This is a record of behaviour rather than a log of intentions, and it is produced by the boundary rather than by the agent being watched.

Entries are linked, so a missing or altered one shows. Entries are linked to one another, so the record cannot be quietly edited after the fact. Removing an entry, reordering two, or altering one changes what the whole set adds up to, and the mismatch is visible to anyone checking. That is what makes the record worth reading later: its value comes from being tamper-evident, not from anyone promising it has not been touched.

You can check any entry yourself, without trusting who served it. You can check any entry yourself. The dashboard verifies that an entry really belongs to the record it claims to belong to, in your browser, from the entry alone — nothing about that check depends on trusting the machine that served it. The full cryptographic proof behind a decision is verified separately by the command-line tool, which anyone can run without access to your account.

OpenMatter cannot quietly change what an agent already did. The point of all this is that our word is not part of the guarantee. OpenMatter cannot alter what an agent already did, and neither can whoever operates the machine it ran on, because a change would show. That is a smaller and more useful claim than promising good behaviour: you do not have to believe the boundary held, because you can check.

It is an outbound boundary. Traffic that reaches an agent from outside is declared rather than inspected: you say which ports may be reached, and the agent's own sign-in story is what protects them. Nothing about inbound traffic is checked or proven, so treat an opened inbound port exactly as you would on any other service.

A host that is allowed but not inspected is checked by name and port only. Nothing about what is sent to it is examined, no credential can be substituted into it, and its traffic produces a thinner record. That is occasionally the right trade, which is why it is offered — but it is never the default, and the policy editor and every summary call it out rather than folding it in with the hosts that are fully checked.

Refusing everything is always available and always safe, and it is where a brand-new policy starts. What the boundary cannot do is guess: if a feature needs a host or a credential you have not named, that feature will not work, and the fix is to name it rather than to widen the policy generally.

A policy set to record only refuses nothing on its lists. What it does not allow is let through and recorded as let through, so you can see what a policy would stop before it stops anything. That makes it a way to draft a policy against a real agent, not a way to run one you rely on: a credential is still added only to requests the policy allows, and every summary and record says plainly that the lists are not being enforced.

The record is kept with the running agent, and it is lost when the agent stops. That is a real limitation rather than an oversight, and it is why the dashboard shows it beside the agent it belongs to instead of pretending to be an archive. If a record matters to you beyond the life of one agent, read it and keep your own copy while the agent is running.

Reading a record needs no sign-in. The entries are published on purpose and each one can be checked on its own, so demanding a credential to read a public artifact would buy nothing and would make independent checking harder. Anyone you hand the address to can verify what an agent did without you granting them anything.

A leaked key opens everything behind it, indefinitely. A leaked credential is not one exposed record; it is standing access to everything the credential unlocks — databases, buckets, deploy keys — for as long as it stays valid. Any system that stores your secrets whole, in a vault, a config file, or a database column, keeps that door ready to leak, because somewhere there is a copy that can be read.

Badged fields are sealed in your browser before anything is submitted. The Quantum Safe badge marks the fields that never take that risk. When you enter an environment variable, a storage credential, or an organization record into a badged field, your browser fetches the committee's joint sealing key and seals the value locally, before anything is submitted. The sealing is threshold encryption designed to withstand quantum as well as classical attack — which is what the badge's name promises.

Only the sealed envelope leaves this page — never the secret. What travels onward is a sealed envelope — a capsule, a proof that the envelope is well-formed, and the ciphertext — and only that envelope is recorded in the Matter Ecosystem. The value you typed never leaves your machine. The envelope is bound to the committee epoch it was sealed under, so it cannot be replayed against a different committee later.

A committee of independent nodes each holds one share. The key generation committee is a set of independent nodes that run a joint ceremony. It ends with one joint sealing key that anyone can seal under, and one share per node that nobody else ever sees. How many nodes sit on the committee, and how many of them must cooperate to unseal, are parameters published in the Matter Ecosystem for each epoch — the dashboard reads them rather than assuming them.

The whole unsealing key never exists, anywhere. There is no moment, ever, in which the whole unsealing key exists. It was never assembled, so there is nowhere it sits waiting to be copied — not on a committee node, not in the dashboard, not in the Matter Ecosystem. That is the difference from a vault: a vault protects a key that exists, whereas the committee never creates one.

Your browser seals under the committee's joint sealing key. Sealing needs only the joint sealing key, which is not secret. Your browser fetches it together with the current epoch, seals the secret locally, and submits the envelope. That is why the plaintext never leaves your machine while the key is never whole: both halves of the guarantee come from the same design, and neither depends on trusting the other end of the connection.

A quorum of nodes unseals; fewer than that learn nothing. Unsealing is the ceremony in reverse. A quorum of committee nodes each apply their own share to the envelope and return a partial result; each partial is checked against that node's published commitment before it is combined, and only enough verified partials yield the secret. Below the quorum the shares are just noise: one compromised node reveals nothing, and a second still reveals nothing.

Each epoch the committee reshares; old shares turn useless. A fixed committee would be a slowly ripening target, so the committee does not stay fixed. Each epoch the nodes refresh their shares, and whatever an attacker collected in the previous epoch no longer combines with anything held now. Against a committee that reshuffles before an attacker has finished mapping it, patience is useless too.

Membership can change, so an attacker's map goes stale. Membership can change at a rotation as well: a node can leave and a new one be seated, and the roster and quorum size in force for each epoch are published in the Matter Ecosystem. Rotation runs on the ecosystem's schedule, not yours — there is nothing for you to trigger or maintain, and nothing you can postpone.

What you sealed stays openable across rotations. Every envelope records the epoch it was sealed under, and when you unseal it the dashboard looks up that epoch's roster, quorum size, and key material rather than today's — so a secret sealed months ago still opens. When a rotation is a fresh ceremony rather than a refresh, your organization's records are carried forward by an explicit re-seal under the new epoch, run in the background when the organization's owner signs in — never by silently reusing the old envelope.

Env vars, storage credentials, and organization records all get sealed. Everywhere this dashboard collects a secret — environment variables on the deploy form and in the edit dialog, volume and backup credentials on Storage, your organization's records in Settings — it goes through the same seal first. There is one custodial layer under every secret: the same committee with the same properties, whichever page you are on.

The dashboard can seal, but never unseal alone. The dashboard can seal anything, but it can never unseal on its own. Every unsealing needs a quorum of committee nodes to each contribute a partial, and each request is signed by the account asking, so a node can refuse anyone who is not on the secret's list. The custodian is designed to be incapable of reading what it holds, and the dashboard is no exception to that design.

You choose who may unseal each secret. Unsealing is a grant per secret, and only the account that sealed a secret can extend it. Launch an app and the app may unseal its secrets where it runs, when it starts. For a project's app, the dashboard also grants your teammates on that project, so they can open the values in the edit dialog; a teammate added later can grant themselves from that dialog. Organization records are granted to the members who need them.

The committee checks that grant before unsealing anything. At unsealing time the committee checks the grant in the Matter Ecosystem before contributing any partial, so possession of the envelope is worth nothing without one. A request from an account that was never granted is refused by every node, and the dashboard says so — naming the secret and the account — rather than leaving you to retry something that cannot succeed.

The seal covers the badged secrets only. That a sealed secret exists, and the label it is stored under, are recorded in the Matter Ecosystem like any other record; so are the things around it — an app's name and image, a volume's bucket locator. The contents of the envelope never are. Your key is protected; its address is not.

The committee can never read your secret, but it does see the unsealing requests: which account asked, for which secret, and when. Each request is signed by the asking account, so this is an audit surface rather than a leak — but it is a surface, and it is the reason the committee can enforce grants at all.

The badge is the signal. An organization without the Quantum Safe entitlement sees its environment variables marked Plaintext instead, and those values are submitted and stored readable. If a field does not carry the badge, do not assume it is sealed.

Sealing protects a secret until the moment it is unsealed. It does not govern what an app does with the value once it has it — which endpoints it calls, what it sends where. That is a separate layer, and the walkthrough does not claim otherwise.

Unsealing needs a live quorum. If too few committee nodes are reachable, the dashboard retries a few times with a short pause and then reports the failure plainly; nothing falls back to a weaker path. A secret that would not unseal just now is not broken — try again.

Rotation is on the ecosystem's schedule, not yours. A secret opens with the roster of the epoch it was sealed in, which needs enough of that epoch's members still reachable; and after a fresh ceremony your organization's records are re-sealed forward in the background when the owner signs in. Until that has run, a record sealed under the old epoch may not open.

Resources are servers and clusters you run for the network. The Resources page lists the servers and clusters your account has registered, with each one's status, capacity, and earnings. In the network's own vocabulary a registered resource is a provider: a machine that has offered to run apps and sessions for everyone else. The rest of this guide never uses that word, because the people deploying apps do not need to know which machine they landed on.

Prove you own the machine with matter-wizard, then register it. Registering starts on your own machine. The matter-wizard utility produces an ownership proof bound to your account address — the address shown at the top of the page — and you paste that proof, the resource's identifier, and its details into the Register New Resource form. The network then records the resource as yours.

Your local computer can autofill its own details. If the machine you are registering is the computer you are sitting at, the form can fill itself in: it asks the local daemon for the resource's details and drops them into the fields, so the only thing you type is the proof.

Fund a resource so it can submit its reports. A resource has to report its status to the network as it runs, and those reports have to be paid for by the resource's own account. Fund Server transfers a balance to the resource for that purpose; the modal recommends a minimum so a freshly registered machine does not fall silent after its first few reports.

Lock part of your balance to stand behind it. Lock Status shows the part of your balance you have locked to stand behind your resources — a commitment that tells the network you intend to keep serving. You can add to the lock, and unlocking takes effect after a waiting period the card shows as Unlocking.

Earnings arrive per era; the chart projects thirty days. Earnings are credited per era, and the Earnings Overview chart shows recent eras side by side with a projection that multiplies the average of the last five eras out to thirty days. The projection is an estimate from recent history, not a promise.

Public resources accept work from any account. A public resource is open to all: any account on the network may have an app scheduled onto it. This is the default, and it is how the shared pool of compute works.

Private resources accept only whitelisted accounts. Access Control switches a resource to private, so only the accounts on its whitelist may deploy onto it. Use it to reserve a machine for your own organization, or for a partner whose work must not share hardware with anyone else's; the whitelist is edited from the same modal.

Remove or reactivate a resource at any time. A resource you no longer want to offer can be removed, and a removed resource can be reactivated later from its card. Both are actions on your own record of the machine — they do not touch anything already running elsewhere.

The shared record behind every page of DataVizor: a distributed ledger kept by a globally distributed network of servers that reach byzantine-fault-tolerant consensus before anything is written. See the Matter Ecosystem section at the top of this guide.

Your team's workspace: members and their roles, projects, the plan, and everything the team runs. An account belongs to exactly one organization, and the account that created it is its Owner for life.

The organization's unit of scope. A project groups apps, carries the budget they draw down, and bounds what the Members and Viewers assigned to it can see and do.

A container you launch from the Deploy page — from the template gallery or your own image — that runs on the network and appears on your dashboard with its status, ports, and environment.

A pointer to a bucket you already own — bucket, path, and sealed access keys — registered once on the Storage page and mounted into any of your apps at deploy time.

A private, encrypted mesh that puts your apps and your own devices on one address space, wherever they actually run. Created and managed on the Networking page.

The badge on any field whose value is sealed in your browser under a key that no single party ever holds — environment variables, storage credentials, your organization's records. A committee of independent nodes unseals it only for the reader you grant.

The way Collaborate runs a model over several parties' data without any of them handing it over: each party's rows are split into masked pieces on their own machine, independent servers compute over the pieces, and everyone receives the same finished result.

The small program you run on your own machine for Collaborate and the Marketplace. It reads your data locally, prepares it, and is the only thing that ever sees your rows in the clear. You install it once; it keeps itself up to date and installs a newer release only when you click.

A server or cluster you operate and register on the Resources page so the network can schedule work onto it. Resource operators are the only people who need to think about the machines apps run on.