The Action Graph

Everything Frontlatch does starts with one thing: a written list of what your site can actually do, in a form a machine can read.

For each action it records four things. What it is, such as book a job or request a quote. Where it lives. What it needs from the customer, field by field, with the rules your site already enforces. And what happens when it runs.

That list is built by a real browser, not by reading the page source, because most of what a site can do only exists once the page has loaded and something has been clicked. Every format an agent can read is generated from the same list, so there is one source of truth and no second copy to drift.

It is a contract, and it is versioned #

The list is the one thing every part of the system agrees on. The scanner writes it, the compiler turns it into agent formats, and verification and execution work from it.

It carries a version number. A reader that meets a newer version refuses it, because the newer list might state a limit this reader cannot see.

The shape of one action #

Take the booking form on a dental practice. Its entry says it is a booking, where it lives, and each field it asks for, such as a name of at most 80 characters. Last come the consequences: the practice gets an email, and a slot is held.

Nothing is left out: a field with no value says so. An action cannot be marked approved without the approval attached.

What an action is, and how it is reached, are separate #

An action’s kind is what a customer is trying to get done: booking, quote, callback, contact or enquiry. How to reach it is a separate list, since one action can have several ways in, such as a form, a phone link or a third-party widget.

A widget whose fields sit inside someone else’s frame is recorded as a real booking we cannot see into, which is different from an action with no fields. A form repeated in two places is counted once.

The word lists are closed #

Every field that takes one of a set of values draws from a fixed list. A value outside it is rejected, and each list has an “unknown” entry.

What a field means #

A field has what the browser thinks it is, such as text, and what the business thinks it is. An agent reasons over the second: two text boxes may be a name and a property address. There are 32 meanings.

What running an action does #

Consequences are chosen from a list of 12, not written as a sentence, because a machine cannot check a sentence. The list covers emails, records created, a calendar slot taken, a callback, quote or ticket requested, a call placed, a marketing sign-up, an account created, a payment taken, and unknown.

An action also states whether it can be undone, whether personal details are sent and whether money moves, plus a one-sentence summary: the line an owner reads when they approve it. An action with no stated consequences is invalid.

Every claim says how it came to be believed #

Anything the list asserts carries a record: how we found it, how sure we are from 0 to 1, when, and the evidence. Only an owner’s confirmation can reach exactly 1.

A rule the site states itself may be used to reject an agent’s input. A rule we guessed can warn or lower a score, but never refuse a legitimate request.

Nothing can be marked approved without the approval #

The rule the whole system is built around is that no action ever runs against a business that has not approved that action type. In the list, that is not a policy paragraph. It is the shape of the data. An action is in one of three states:

• Unverified: the starting point for every action. Nothing runs.
• Sandbox-tested: it has been run in test mode. Still nothing runs live, so “the test passed” can never be mistaken for “the owner said yes”.
• Verified: the owner confirmed, and the confirmation is stored with it. Who, when, how, the limits they set and the exact consequences they were shown.

Withdrawing approval sends the action back to unverified. Several independent checks hold the line: the data format and the validator both refuse a verified status without its confirmation, and nothing in the package can create a verified action. The gate in front of execution ignores the status label and re-checks the confirmation on every call: who gave it, that it can be looked up, that it sets a volume cap, and that it covers today’s consequences. Anything short of a clear yes returns no.

The gate checks consent, not the attempt; the hosted runtime enforces hours and caps.

Consent is tied to consequences #

An owner does not approve an action’s name. They approve what it does. So the confirmation stores everything they were shown, and the gate compares each item against what the action says now. Any difference stops execution until a person confirms again.

An early version recorded only the kinds of consequence, so switching on “charges money” still passed. The list of approval-bearing fields is now written once and the comparison runs over it, so a new field is compared automatically. The one exception is how we worked the description out, which would void approvals whenever a rescan nudged a confidence score.

The summary is compared character for character, and an empty summary never counts as consent.

Complete is not the same as executable #

Complete is about our knowledge: do we have a faithful map of this action? Executable is about the owner’s consent: may it run? A fully mapped action on a site whose owner has never heard of us is complete and not executable, which is the normal state of every action we have mapped.

An action is complete when all seven of these hold:

1. At least one way in that we can actually drive, so not a third-party frame and not a phone link alone.
2. A usable way to send it, so not JavaScript only, and a form with a real submit button.
3. At least one field an agent may fill.
4. No required field whose meaning we could not work out. An agent would either leave it blank and be rejected, or guess and send wrong data to a real business.
5. A way to reach the customer back, an email or a phone field.
6. Consequences stated, with none of them unknown.
7. A record of how we know, on the action and on every field.

Obstacles such as a CAPTCHA or a login are reported separately and do not affect completeness.

The check returns its reasons, not just a yes or no. Across fifteen sites, 49 actions were detected and 20 were complete; the commonest failures were a phone link as the only way in and a form with nothing to fill. The 40.7% at the top counts sites, not actions. A site with no actions scores 0, not 1.

Every action the scanner produces starts unverified. None of the 49 could run, because only the business confirming it moves an action to verified.

What may change, and what needs a decision first #

Changing the contract is a governed act, not just a commit. Adding an optional field, a word-list entry or a helper is safe within the current version. Removing or renaming anything, changing what a word means, touching the approval states or the gate, changing what complete means, or raising the version needs a recorded decision first. The trust rule does not move quietly.