Inspect another resource purpose
Compare skills, references, workflows, and advisory guidance.
Open this resource →Reference explanation
Tell the next person what is ready.
Understand Delivery evidence through an artifact handover, scoped verification claims, and explicit delivery state.
The next reader should know what exists and what they can do with it. Explore how Delivery evidence makes that handover clearer.
01 / Reference explanation
Make the handover answer the next question
A Search developer asks for a report showing slow queries. The agent creates the report locally, but the operations team expects a shared published artifact.
A completion message that omits that distinction can send the next person to a location that does not contain the new work.
Delivery evidence helps the agent communicate the state that actually exists. The reference applies to investigations and artifacts as well as code changes.
This page uses a fictional reporting task. Its examples demonstrate useful communication; they do not describe an artifact created by Betterloop.
Start with the reader's next action. They may need to inspect a file, approve publication, run a release, or resolve an unverified behavior.
The final account should give them enough evidence to choose that action. Routine implementation detail belongs only when it changes the decision.
02 / Reference explanation
Catalog identity for this example
| Catalog property | Recorded value |
|---|---|
| Published resource name | Delivery evidence |
| Catalog identifier | betterloop.delivery-evidence |
| Type | Reference |
| Version | 1.0.0 |
| Maintainer | Betterloop platform catalog |
| Catalog state | Ready for selection |
| Company review state | Company approval is still required for release |
| Declared clients | Claude Code and Codex |
| Dependencies | None |
| Required configuration | No company-specific values are declared |
| Permissions | Selection supplies no extra authority |
03 / Reference explanation
The reference’s intent in different words
Explain the outcome the user requested, then identify the result now available. Connect the delivered change to that requested outcome.
Describe verification using observations that actually exist. Proposed commands and intended inspections should not appear as completed checks.
State what the observations establish within their real scope. A small sample can support a sample result without proving every possible input.
Distinguish source work, successful checks, deployment, and publication. Each state can be true while the next one remains incomplete.
Name a remaining limitation when it changes the reader's interpretation. The reader needs a precise boundary rather than a general warning that anything might fail.
This paragraph is an editorial explanation of REFERENCE.md. It does not reproduce the installed text or change the resource's actual reporting requirements.
04 / Reference explanation
Prepare an artifact handover
- 01
Identify the requested use
Record who needs the slow-query report and where they expect to access it.
- 02
Inspect the delivered file
Verify that the artifact contains the requested information.
- 03
Inspect the actual checks
Review available output from generation and any direct content validation.
- 04
Determine the delivery state
Check whether the artifact is local, shared, or published.
- 05
Identify the next dependency
Name the approval or action still required for the reader’s intended use.
- 06
Write the useful conclusion
Lead with the result and its present availability.
05 / Reference explanation
Compare a report with its evidence
For the example, the agent generated a local report from a small sanitized fixture. It inspected the headings and the displayed slow-query entries.
Those observations support a limited conclusion about the generated sample. They do not establish that a production data connection works.
Practice handover:
The local report lists the sample queries by duration.
I checked the headings and the three supplied sample entries.
The generated file is available for review.
A live data connection was outside this check.
Publishing the report still needs authorization.The limitation explains what a reviewer can safely infer. It avoids making the next person discover the production-data gap through an unsuccessful rollout.
If the agent later receives publication authorization, inspect the actual destination after publication. Add that observation rather than assuming that an upload request succeeded.
06 / Reference explanation
Choose the claim the evidence can support
| Available observation | Reasonable statement | Further evidence needed |
|---|---|---|
| A generated file exists. | The local artifact was created. | Inspect its contents and usability. |
| Sample content was inspected. | The inspected sample matches the expected values. | Evaluate other relevant cases separately. |
| A relevant check passed. | The tested behavior passed under the recorded conditions. | Inspect any environment outside that check. |
| A release was initiated. | The release operation started. | Confirm completion and resulting behavior. |
| A shared destination contains the artifact. | The artifact is available at that destination. | Check any access requirements the audience depends on. |
07 / Reference explanation
Keep the report grounded during a repair
Suppose report generation initially fails because an expected fixture field is absent. Preserve that output rather than describing the first attempt as successful.
After the repair, execute the relevant generation again. Compare the new output with the expected report content before changing the result statement.
The reader usually needs the final observed state and the important remaining limit. They rarely need every command from an uneventful investigation.
A failed attempt matters when it leaves a requirement unresolved or explains a material constraint. Keep that information precise and brief.
If a check cannot run, say what is missing. Another developer should understand how to continue without reconstructing the entire conversation.
A repair plan is not proof that the repair works. The report should change when new evidence exists, not merely when the agent expects success.
08 / Reference explanation
Use evidence without treating it as authority
A deployment guide may explain how a release works. Its presence does not authorize the agent to deploy the current change.
A retrieved document can also contain outdated assumptions. Compare its instructions with the current repository and the actual task authority.
The reference helps an agent describe what happened; it does not grant permission for an operation or manufacture an audit approval.
Keep sensitive data outside the public account. A useful outcome statement can describe a successful check without copying credentials or private query values.
The reference does not automatically gather logs, upload screenshots, or attest to machine state. Actual task evidence comes from the relevant local work and observations.
If formal audit records are needed, use the organization's established workflow. Better reporting prose does not replace those records or their access controls.
09 / Reference explanation
Evaluate adoption with a reader
Choose a task where the difference between local completion and delivery matters. An artifact handover or an undeployed service change provides a useful example.
Confirm that betterloop.delivery-evidence 1.0.0 is the reference selected in the reviewed release. It declares no dependency in this catalog example.
Ask a colleague to read the resulting handover without the original conversation. Check whether they can find the result and identify its current state.
Compare every verification statement with its supporting observation. Remove claims that extend beyond what the check actually covered.
If the content is unavailable, investigate selection and signed retrieval. If the report is confusing, examine the task and how the agent used the reference.
A short accurate handover can be the successful outcome. Extra headings or longer prose are not a useful adoption target by themselves.
10 / Reference explanation
Agree on what the next reader needs
Teams can use the reference across code, documents, and investigations. The required detail changes with the consequence of misunderstanding the result.
For a small correction, a few connected sentences may cover outcome, evidence, and availability. A complex release may need a more structured account.
Keep the relationship between claim and evidence consistent. A reader should not have to guess whether “finished” means created, checked, deployed, or published.
Review that relationship when evaluating a new resource version. Better handovers should reduce ambiguity about the next action, not increase report volume.
11 / Reference explanation
Questions about delivery reports
Does the reference require a fixed final-answer template?
No. Include the information that makes the outcome assessable. The structure can remain proportionate to the work.
Can a final report prove permission existed?
No. Permission must come from the applicable authorization. A result statement explains evidence about an action.
Should a successful build be omitted?
Include it when relevant, with its actual scope. Do not use it to imply runtime behavior or deployment that was not checked.
12 / Reference explanation
Take the example through your own review
The public explanation is a starting point for evaluation. Inspect the exact resource files selected by your company before accepting a configuration change.
Keep the catalog identity and dependency versions attached to that review. The reviewed release should supply the same content the owners examined.
Selection creates reviewable configuration content; it does not by itself approve or activate it. Follow the normal signing and team adoption process.
On the developer device, complete required native trust and session activation. Then examine resource retrieval and the representative task as separate observations.
A signed release establishes the reviewed content and scope. It does not guarantee that the native agent follows every instruction.
Use the approval workbook when the example requires additional operations. Resource advice and authority to execute a tool remain distinct decisions.