What a Site Records for a Job¶
A site keeps its own record of what the Hub asked it to do, so it does not depend on the Hub's records. Every statement it receives is stored before any work starts, every change a job makes shows in the site's revision history, and a statement that looks forged or misdirected raises an alert at the site.
The Site's Record of Each Statement¶
The site stores every statement it receives in its database, whether it accepts or refuses it, before it does any work. Each record holds:
- The signed statement itself, with when it was issued and when it expires.
- The person it vouches for: their user id, name and role at the Hub, and how they signed in there.
- The approver, for a job that was approved.
- What it allows: a step and which one, a question about an earlier step, or a rollback, with the job it belongs to.
- For a question or a rollback, the statement it refers to.
- When the site received it, when the work started and finished, how it ended, and its result.
- For a refused statement, why it was refused.
A statement can be used only once. A second statement with the same id is refused, so a captured statement cannot be replayed.
This record is what the Hub asks about when a step's answer did not reach it, and what the check step's "since" checks count from. See Job Site Outcomes and Job Check Step.
The site keeps these records for the number of days in Audit Retention (days) on its MCP page, and deletes older ones each night. When that value is 0, it keeps them all. See MCP Settings.
Revision History¶
Every change a job step or a rollback makes at the site appears in the object's revision history, with Via set to Hub Job. A step's changes are made by the preparer's Hub user; a rollback's by the Hub user of the person who asked for it. Each such revision also carries the id of the statement it was made under, which is how a rollback finds what an import changed.
Refusals and Alerts¶
The site refuses a statement it cannot trust or may not act on, records the refusal, and tells the Hub why. Some refusals raise an alert at the site, and others do not:
| Refusal | Raises an alert |
|---|---|
| The statement cannot be read, is not signed by this site's Hub, or its signature is not valid | Yes |
| The statement is for another site, or from another Hub | Yes |
| The statement has expired, or was signed in the future, beyond the allowed clock difference | Yes |
| The statement was already used, or allows another kind of action | Yes |
| The details sent do not match the statement | Yes |
| Use Hub is off at the site | No |
| The person's Hub role matches no Role Map entry | No |
| The site disabled the Hub user of the person, or of the approver | No |
| The person has made more requests than the site's limits allow | No |
An alert is added to the site's alerts and, when alerts are enabled, emailed to the site's administrators. Each node raises at most one alert for a given reason in ten minutes; every refusal is still recorded.
A refused step fails that site's part of the job at the Hub; see Running a Job.
Per-Person Limits¶
Job steps and rollbacks count against the site's per-person limits, which are the values of Requests per Token per Minute and Concurrent Requests per Token on the site's MCP page, applied to each person the Hub vouches for. They apply whether or not the site's own MCP server is on. Questions about an earlier step do not count. The first refusal of a person in a minute writes a rate-limit entry to the site's MCP audit log. See MCP Listener.
Developer Licenses¶
When a start, resume or restart step reaches a site with a developer license, the site leaves the channels as they are. It writes a warning to each channel's log saying the Hub request was ignored because a developer license is installed. See Job Channel Steps.
The Hub's Side¶
The Hub keeps its own records of the same job. Every statement it signed is in its database and in hub-audit.log. Every job action, from creating a draft to the end of the job and every rollback asked for, writes a Hub audit entry. The Audit Log page lists these under event types that begin with JOB_. See Access Control and Audit Log and Job Retention.