> ## Documentation Index > Fetch the complete documentation index at: https://docs.erdo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Automatic capture maintenance > How capture contract faults are repaired, checked, and reported. Erdo checks captured rows against a dataset's declared columns. If a writer sends unknown fields or omits required fields, capture keeps the submitted rows and records the mismatch. Keeping a row does not make an undeclared field available to reports that use the declared contract. ## 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. Verification describes the contract and captured submission at the recorded check time. Later contract changes or new faulty submissions can raise a new finding; a completed repair is not a permanent guarantee. Verified recovery appears as an informational update. A verified required-field repair describes the particular page that passed; it does not claim that every writer into the dataset is repaired. Failed or unverified repairs remain visible through the original finding and repair record. Limits prevent repeated repair runs from becoming an open-ended spending loop. ## Older warnings New schema findings retain the dataset identity and separate machine-readable lists of unknown fields and missing required fields. Recovery uses that exact cause evidence rather than interpreting the warning's wording. Older findings can lack structured cause evidence or the identity of the writer that caused the mismatch. Automatic recovery checks a limited recent finding and event history; a cause outside that window, missing evidence, or ambiguous evidence leaves the warning open. It does not guess from prose. Dataset-wide warnings without producer identity do not establish which writer caused a missing-required mismatch. Unknown-field warnings can be recovered once the current contract declares all of those fields. A valid submission from one page cannot safely close an older missing-required warning: another writer may still be broken. Those warnings remain open until their cause is independently established. The expiry date on a finding is its review deadline. It does not mean the underlying technical fault will automatically be repaired on that date. Direct page submissions keep their captured data even when the submitter can only view the page. Starting automatic repair as the page owner, or proving that page repaired, additionally requires the initiating caller to have independent page-edit permission. A page’s delegated permission to write data does not grant permission to edit the page itself. Older events without verified repair authority cannot start owner repair. A repair that was dispatched keeps its place until its exact run and any related approvals are proven finished. An old timestamp alone does not start another paid repair. If approval history or run status cannot establish that work has ended, further repairs stay on hold; approved historical requests currently require this conservative hold because their later execution cannot be verified from the available status records. Delayed progress reports cannot restore an outdated approval request after a newer completion check. The update reflects the current repair evidence, even when the repair remains in the same status. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.