What happens automatically
A contract fault from an authorized page write can start a repair only after the repair service confirms the page belongs to the same workspace and is linked to the exact dataset. It runs under the page owner’s existing permissions and approval settings. The repair inspects the page and dataset, then corrects the writer or the contract when the evidence establishes the intended fields. It must preserve capture and existing rows. A public-page edit still uses the normal approval gate; automatic maintenance does not override your approval policy. Repeated faults share a durable repair record. The same cause is debounced for seven days and has a lifetime limit of three attempts. A page also has a ceiling of three attempts across causes in seven days, and only one contract repair or pending contract-repair approval can occupy its repair slot at once. A crashed repair can release its slot after thirty minutes.Event pipeline maintenance
Automatic repair of event pipelines runs only where pipeline repair is enabled. It uses the existing repair permissions and approval policy. Repeated faults have a seven-day same-cause debounce, three lifetime attempts for that cause, and a separate limit of three launches per pipeline in seven days. If a dataset contract blocks a conversation capture before it starts, the conversation stays queued. If the same check fails after the repair finishes, Erdo marks that repair as failed and can try again without waiting seven days. The three-attempt limits still apply. Each distinct accepted-write fault is retained in a durable queue, including faults affecting multiple datasets in the same submission. Waiting entries do not count as paid attempts. Repairs run one at a time and wait while an approval is pending. Completion and a periodic recovery check revisit the queue, including after a restart. Before starting work, the service checks the current pipeline, its dataset links and the original contract fault again; a cause already fixed is removed without launching another repair. Existing permission, approval and spending limits still apply. If a pipeline repair stops before its run can start, periodic recovery puts its original cause back in the queue. This does not count as another paid attempt. A repair with evidence that its run started remains on hold until that run and its approvals can be checked; age alone does not authorize a replacement. Repair notices follow the latest attempt. Delayed messages from an older attempt cannot reopen a fixed warning, replace a newer outcome, or clear a newer warning. A pipeline repair is checked against a subsequent real execution of that same pipeline. A verified completion update names the repaired producer; it does not silently close an older dataset-wide missing-required warning that never recorded which writer caused it.How a repair is verified
An agent saying it finished is not proof of recovery.- For unknown fields, the current declared contract must include every original unknown field before the corresponding schema warning can be recovered.
- For missing required fields, a subsequent real submission from the same page must satisfy the contract. The original fields must still be declared and required. Removing a requirement, a synthetic test, or a zero-row write does not establish recovery.