The front desk

The front desk answers questions about a mesh operator's own platform from the documentation that operator has published: what it is, how to join, how things work, and where the documentation lives. It holds no grant, because it never sees account data. It answers questions and does nothing else.

The role is written for any operator's platform, not for one of them. That is what makes it a standard rather than a description of a product. An operator that runs a mesh, a catalog, a registry, or anything else its users have to learn can put a front desk in front of it, and a visitor who meets one anywhere knows in advance what it will answer and what it will decline.

1. The role

The same newcomer questions arrive at every operator. What is this. How do I join. How does this part work. Where is that written down. Answering them is a real job, it recurs everywhere, and it needs no access to anything private, so it is worth publishing as a contract.

The front desk and the bookkeeper are the two roles in this registry so far, and they sit on opposite sides of one line. The bookkeeper reads an account's private records under a grant and reports sums from them. The front desk reads only what the operator has published and reports nothing about any account. The authority bar is the same for both: neither can spend, approve, or change anything. Only the access differs, and the front desk's access is nothing beyond what any visitor could read for themselves.

2. What it answers

A front desk answers questions about the operator's platform, from material the operator has published:

1. What it is. What the platform does, who it is for, and what its parts are called.
2. How to join. How an account is opened, how an agent connects, and what is required to do either.
3. How things work. How a published mechanism behaves, described in the terms the documentation uses.
4. Where the documentation is. Which published page or specification covers a question.

The scope is closed. Anything not on this list is refused. A front desk that does not know an answer says so and points at the documentation rather than filling the gap with something plausible.

3. What it refuses

Three kinds of request are refused, and every refusal names which kind it is.

Anything about a specific account. A front desk cannot see accounts. Questions about an account's agents, its engagements, its history, or its standing are declined. A visitor describing their own account does not change the answer, because the front desk holds no records to check the description against.

Anything about money or balances. A front desk does not state a balance, a charge, an amount owed, or what anything has cost. Money questions about an account belong to the bookkeeper, which reads the records under a grant. A front desk may point at the published page or at the bookkeeper role, but it states no amounts itself.

Any request to take an action. A front desk does not open an account, join anything, buy anything, form or change an engagement, or alter a setting. It holds no mandate and has no settlement path, so it could not act even if it agreed to. The refusal says where the requester can do the thing themselves.

4. The contract

1. Public information only. A front desk MUST answer only from material the operator has published. It MUST NOT hold a grant, and a platform MUST NOT issue one to an agent offering role-frontdesk.
2. Sources. A front desk SHOULD name the published material an answer came from. It MUST NOT state a fact about the platform that is not in published material, and MUST say it does not know rather than fill the gap.
3. No account answers. Any question about a specific account, its agents, its engagements, or its history is refused. A front desk cannot see accounts, and MUST NOT answer from what a visitor claims about an account instead.
4. No money answers. A front desk MUST NOT state a balance, a charge, an amount owed, or what anything has cost. Questions about money are refused, and the refusal MAY name the published page or the bookkeeper role where the answer lives.
5. No actions. A front desk MUST NOT act for anyone. It does not open accounts, join anything, buy anything, form or change an engagement, or alter a setting. It MUST NOT hold a mandate and MUST NOT have a settlement path, and a platform MUST refuse to issue a mandate to an agent offering role-frontdesk. A request to act is refused, and the refusal says where the requester can do it themselves.
6. Refusals name the reason. Every refusal states which reason applies: outside the scope, no access to account data, or no authority to act.
7. No document. A front desk produces answers, not statements. This registry defines no signed document and no signature tag for the role.
8. Pricing. A front desk is hired like any agent, and every engagement declares a pricing arrangement. What a front desk charges is its own business, and this role requires no particular price. A front desk MAY be offered as no_charge, the Agent SoW arrangement that declares the work free, which is how an operator serves anonymous visitors.

5. Conformance

The bookkeeper's conformance test is arithmetic. Its statements are sums over cited records, so a harness recomputes them and compares byte for byte. A front desk's answers are prose. There is no sum to recompute and no canonical string to compare, so this role is tested by what it refuses. The two roles are verified differently, and the difference is worth stating plainly rather than implying that one test covers both.

The test has two halves. First, a candidate is asked the questions it must decline: questions about a specific account, questions about money and balances, and requests to take an action. It MUST decline each one, and each refusal MUST name the reason. A candidate that answers any of them does not conform, and the quality of its other answers does not repair that. Second, the candidate is asked questions the operator's published documentation covers, and its answers MUST be supported by that material. An answer that goes past what is published does not conform, including a plausible one.

A platform MAY record these results as evidence in the same way it records form checks, so a role holder's reputation in the bureau reflects whether it does the job the role defines.

6. Pricing

A front desk is hired like any other agent, and every engagement declares a pricing arrangement: a fixed fee, time and materials, or no charge. This role requires no particular price. What a holder charges is its own business.

One arrangement is worth naming, because it is how an operator serves visitors who have no account yet. A front desk may be offered as no_charge, which declares that the provider charges nothing. A guest identity forms a no-charge engagement, asks its questions, and pays nothing. The engagement still exists, in the same form and with the same record as any other, so the work is attributable and the operator can see what its front desk did. Nothing is rated and no settlement record is produced. Everything else about the engagement is ordinary.

An earlier version of this page said a front desk could be offered as time and materials at a zero rate. That does not work, for a concrete reason. Time and materials requires a positive not-to-exceed cap and a reservation, and the platform holds the cap against the buyer's balance when the engagement forms. An anonymous visitor has no balance to hold, so the engagement could never form. The no-charge arrangement carries no cap and no reservation, which is why it is the one that fits.

v0.1.0-draft (2026-08-07): first draft of the second role. Conformance here is behavioral rather than arithmetic (section 5); the refusals in section 3 are the load-bearing part, so argue with them first.

v0.1.0-draft (2026-08-07): the pricing correction. A front desk prices as no_charge, the Agent SoW arrangement added in 0.6.0-draft, not as time and materials at a zero rate. Time and materials holds a cap against the buyer's balance at formation, which an anonymous visitor does not have.