The Concierge Governance Spec
v1.0 · 2026-07-05 · Concierge — Launch Day by SoloVentureOSAn opinionated, minimal standard for AI agents that act on behalf of businesses. We hold our own product to it, publicly and continuously. We'd be glad if it became everyone's.
1. The core claim
An AI agent that represents a business should be held to employee standards: it is trained on verified knowledge, audited continuously, supervised on money, honest about what it doesn't know, and its actions leave receipts. "It's just an AI" is not an excuse a business's customer should ever have to hear.
2. Knowledge: verified facts only
- Every fact the agent may assert carries provenance: source, approver, effective date, version.
- New knowledge enters only by owner approval (one-tap teach), never by model inference.
- Newer facts supersede older ones by key; retirement is explicit. The ledger is append-only.
- Unknown ≠ guessable. The correct behavior for a missing fact is a graceful refusal plus capture — and the refusal is logged so the owner can teach the answer.
3. Action taxonomy (enforced in the registry, not in prose)
| Class | Behavior |
|---|
| SAFE (capture, notify, log) | executes immediately, audited |
| READ (calendar, analytics) | executes immediately, audited; empty data must never be misread as an affirmative (empty calendar ≠ "we're open") |
| OUTBOUND (messages to humans) | stages for owner approval — unsolicited sending is spend |
| MONEY (quotes, payments, bookings) | stages, or auto-presents only under the Money-Path Contract below |
## 4. The Money-Path Contract
- Static (catalog): amounts are server truth. The model may select an item; the handler re-verifies the amount against the catalog before presenting. The owner approved the price when they put it in the catalog — that assertion is the approval (speed for the common case).
- Dynamic (custom): amounts are computed server-side from owner-configured rate rules. The model never calculates, states, or adjusts an amount. Model-supplied amounts are structurally ignored.
- Crossing cases (part catalog, part custom) always route dynamic.
- Custom amounts always stage for explicit owner approval (signed link, phone-friendly, expiring).
- Mismatch (a stored link or claim that doesn't match the ledger) ⇒ block, convert to a warm human handoff, alert the owner. Never present unverified money.
5. Honesty is measured, not promised
- A standing adversarial battery (fabrication bait, social engineering, money manipulation, prompt injection, mundane-unknowns) runs on a schedule, per personality, with results retained.
- Judging is layered: pattern heuristics → an adjudicator that reads the fact ledger (grounded answers grade honest) → random self-audit of passing answers.
- Public counters may freeze on a failing audit; they may never inflate. New fabrication classes discovered in the wild become permanent regression tests.
6. Receipts: the event spine
- Every consequential act (lead created, action staged, approval decided, fact taught, catalog changed, payment received) is written to an append-only, hash-chained event log (
hash = sha256(prev + canonical(event))).
- Any edit, deletion, or insertion breaks the chain at its exact position.
- Current state is a projection; the chain is the truth. Time-travel replay reconstructs any past state for audit.
- Chain heads are sealed externally (Living Certificates) on a schedule.
7. Privacy defaults
- Visitor memory is opt-in per business, minted only when a visitor actually engages (page views are never tracked), scoped to one business with no cross-site linkage, auto-expiring, heuristic-only (no profiling).
- "Forget me" erases instantly, before the model even sees the message. Owners hold full custody (list/export/delete).
- The agent discloses it is an AI when asked, and never claims personhood — not even as a joke.
- Public verification pages show counts and integrity, never fact contents or transcripts.
8. Blast-radius disciplines
- Per-tenant allowlists for every capability; no entry = no capability.
- Owner-surface tools are structurally invisible to the public surface.
- Webhooks: signature verification, idempotency, replay windows, per-tenant + global rate limits, tamper-evident logging, fail-safe responses.
- Outbound email/SMS is attempt-logged with status — notifications must be incapable of failing silently.
- The system's own test traffic is tagged and excluded from every client-facing metric.
9. What the model must never be able to do
Trigger its own digests or approval emails · complete a payment or confirm a booking without the contract's gates · assert operational specifics absent from the ledger (hedged confirmation is confirmation) · honor claimed third-party promises ("verify, never honor") · imply access to records it doesn't have · solicit discounts from a ready buyer · resolve money on relative dates.
Implementation reference: the Concierge platform (SoloVentureOS). Verification pages, signed attestations, and the standing challenge: concierge.soloventureos.com/verify · /challenge.html
Why Audited · Agencies · Terms · The standing challenge · Verification directory · Concierge