# Understand and resolve a result Identify which check reported the result and which commit it checked. An agentic verdict after a push and a sealed CI protection status are separate evidence. A red job or a timed-out model alone does not establish that the behavior broke. ## A result from the push check | Result | Interpretation | Next action | | ------------------------------------------------- | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | | Kept | Passing cases were exercised on the checked commit. | Continue with those evidence limits stated. | | Broken | A reproduction failed on the changed commit and passed on the base, verified by the runner. | Inspect it, repair the behavior, and preserve a regression test. | | Could not tell | No usable verdict. | Read the reason, restore the missing prerequisite, and rerun. | | No promise selected or an unchecked promise named | The check did not establish whether that promise holds. | Inspect selection or anchoring if the promise should apply. | Read the exact meaning with `get_promise` and inspect the locally kept reproduction. The pushing agent is told to repair behavior, move the reproduction into your ordinary test suite, link it to the promise, verify it, and commit it with the repair for review. See [the repair loop](/docs/check-on-push.md#from-a-reproduced-break-to-a-regression-test). If the person deliberately requested the changed behavior, the agent asks before reversing it. An intentional change to agreed meaning needs the owner's agreement. If an existing sealed check missed the break, propose a verifier repair without changing meaning. An agentic broken result can raise an attention item for the owner. It does not change the sealed protection posture. A later kept report on a descendant commit can resolve that local-check finding without inventing authoritative CI evidence. ## Decide what kind of CI problem you have | Observation | Interpretation | Next action | | ------------------------------------------------------------ | ----------------------------------------------------- | ---------------------------------------------------------------------------------------- | | No verifier has qualified | Agreed but Unprotected; agentic checks can still run. | Continue checking on push; qualify a sealed verifier if you want that protection status. | | A completed verifier refutes an agreed case | Behavior was reported broken. | Investigate the behavior at the checked commit. | | The verifier crashes, times out, or yields no usable verdict | Unknown. | Restore the check's ability to produce evidence. | | Materials or workflow identity cannot be verified | Evidence cannot establish protection. | Inspect identity/material changes and requalification. | | A PR passes while the promise is Threatened | The PR did not update default-branch state. | Check the authoritative run after the repair reaches the default branch. | See [lifecycle and states](/docs/promise-lifecycle.md) for the complete vocabulary. ## When the behavior is broken Compare the agreed failure to the customer-owned results at the reported commit. For the invited-teammate example, a test might show that joining now requires another repository. Repair that flow; do not change its expectation merely to obtain a pass. If the team wants different behavior, propose revised meaning for the owner. Recovery of the sealed protection state requires eligible default-branch evidence for the repaired commit. A local pass, agentic kept result, or passing PR is useful evidence but does not clear that state by itself. ## When the result is Unknown 1. Read the specific reason: missing or canceled run, execution error, timeout, stale binding, or unverified identity. 2. Inspect the customer-side diagnostics. Keep source, logs, credentials, and raw output in your environment. 3. Restore execution or follow the supported qualification path without changing agreed meaning. 4. Obtain fresh evidence. Do not replay an earlier result or edit stored outcomes. 5. Read what it establishes: pass, refutation, or continued uncertainty. Balladeer may restore verification automatically after material changes. Read its progress before starting another repair. Quiet recovery does not make the evidence green during the gap, and a failed requalification is not a fixed check. ## Pull requests and the default branch | Evidence | What it can establish in Balladeer | | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | Local test run | Feedback about that execution; no protection-state update. | | Agentic push check | An advisory verdict on selected promises and the checked change; no sealed qualification or posture update. | | Pull request into the enrolled default branch | Advisory sealed CI evidence; no qualification or posture update. | | Eligible push to the protected default branch | Authoritative sealed CI evidence that can update posture and qualify a verifier. | A passing PR does not clear a broken default-branch result. Results at different commits are not contradictory. Local block mode can hold an agent's push; your GitHub branch rules determine whether tests block merging. ## Notifications and attention When Slack is connected and routing is configured, notifications can bring a broken promise or a promise needing its first check to the team. Follow the actual link and commit. A recorded installation does not prove a person received a particular message. The agent's session-opening counts separate proposals awaiting your agreement, agreed promises without sealed verifiers, and broken promises. Reading those counts does not resolve the action. ## When you need help Give support the promise link, check type, commit, observed time, and bounded reason. Keep credentials, sign-off codes, raw logs, reproductions, and source out of promise text and support messages.