DocsConcepts / Verification and the trust gate

Verification and the trust gate

One rule sits in front of everything: no action ever runs against a business that has not verified that action. Not a setting, not a default. There is no path around it.

What verifying an action means

Verifying an action means the owner has seen it, approved it, and set the terms: the hours it can run, how many an agent may create, and which fields an agent may fill. Until that happens the action exists only in test mode, where nothing reaches the business.

A verified completed action

A verified completed action is the unit we bill. It is one real outcome, a booked job, a submitted quote, an appointment, that ran through a verified action and completed. Duplicates do not count. Attempts do not count. Every one is logged with the agent’s identity where the agent offers it, and can be replayed, so an argument about whether a booking happened is settled by the record.

How we hold ourselves to it

5,449

outbound requests audited across fifteen businesses we have never spoken to — none carried anything we typed

The guarantee that was actually measured is that nothing we type reaches a business, which is stronger than never submitting and is the one that can be checked from outside.

Source: packages/mapper/benchmark/outbound/ · 26 Aug 2026

Written from

  • The words on this pageapps/web/MESSAGE-ARCHITECTURE.md§12.6, verbatim.
  • The rule itselfCLAUDE.mdNon-negotiable rule 3, the trust invariant this repository is built under.
  • The architecture it sits indocs/03-build-architecture.md
  • The outbound auditpackages/mapper/benchmark/outbound/Directory, not filenames: the files inside are named after the businesses scanned.