# Truthful completion reports

Lead with the requested result and its actual state. Use a short paragraph or compact list,
with artifact links where available; keep detailed provenance in the task's existing receipt.
Do not create a new project, record or receipt merely to follow this reporting format. Read-only
answers and standalone work remain possible without studio setup. Required owner checks still apply.

## Saved reports are outputs

An explicitly requested history export, result JSON, Markdown report or other derived file follows
the same [native mutation sequence](workspace-model.md#native-mutation-sequence) as other published
outputs. Successful canonical-record work does not exempt its final reports. Retain the complete
original guards and all complete prepared report bytes/access, finish durable saves, and separately
reopen and validate that full set before its first publisher. Publish complete bytes with the
required no-clobber or guarded-replacement guarantee, then reopen actual destination bytes and
mode/applicable ownership/ACLs and protected sources before reporting completion.

Creating the final public pathname exclusively and then streaming content into it prevents an
overwrite but exposes an incomplete file; it is not complete-byte publication. A later successful
hash or readback does not replace the preparation requirement. Private pending scratch/evidence
may be written while preparing; do not label those paths as completed deliverables or use that
distinction to bypass a requested report's guarantees. Preserve interrupted preparation and inspect
actual state before resuming. Inline answers require no file or publication sequence.

## Evidence to carry forward

| Report element | What to state |
|---|---|
| Source data | Actual files, URLs, records or supplied text used, with relevant source hash/revision, page/range and coverage. Separate retrieved evidence, user assertions and unresolved inference. |
| Arch Studio instructions | Skill owner and semantic specifications followed; exact release digest when known. Separate resources retrieved from native operations actually performed. Unknown provenance stays unknown. |
| Host operations | What the host actually read, fetched, rendered, edited or inspected at the exact target. A connection listing or work-mode name does not prove those operations. |
| Outputs | Actual linked artifacts or inline result, requested versus produced extent, and destination. Distinguish local exports from provider documents and internal controls from client delivery. |
| Validation | Checks that ran, their outcome and evidence limits; identify required checks still missing. A schema pass, hash receipt or inspection flag alone does not verify source truth or visual quality. |
| Unresolved items | Missing inputs, conflicting facts, unparsed coverage, failed outputs and required approvals/capabilities. Keep the original denominator; do not reduce scope to match successful items. |
| Canonical writes | Which owned records or durable instruction blocks actually changed, with fresh target readback and revision where available; say none only when evidenced. Export is not adoption or save to the requested provider. |

Include all applicable elements, combining them naturally. For a simple sourced answer, this can
be a sentence with a source link and a statement that no records changed. For a multi-output job,
preserve itemized evidence in the existing owner receipt and give counts plus material limitations.
Do not expose client-private control files or credentials in a delivery package.

Before reporting, reconcile headline counts, tags, quantities and validation claims with the final
artifacts and their owner receipts at the same delivery cutoff. Keep their denominators and meanings
explicit: observed instances, revision proposals, selected items, generated files and unresolved
items are different measures. A schema-valid output or an accounted-for item is not necessarily
complete. Check that the export uses the owner's schema and that required checks actually ran;
native extraction or a passing unrelated check cannot stand in for a required preservation or validation check.

Derive reported elapsed time from retained start/end readings and explicit excluded intervals.
Use the declared call-counting convention and reconcile category totals with the ledger. If those
records are incomplete or contradictory, state the uncertainty rather than invent an exact total
or budget-stop reason. Resolve report/artifact discrepancies before delivery; when a delivery is
already frozen, retain it and record the correction separately rather than rewriting its history.

## State the observed outcome

- **Full completion:** the requested extent is fulfilled and all owner-required checks and
  target readbacks passed. Allowed unknown source facts can remain explicitly unknown when the
  accepted output contract permits them; do not invent a fact to make a report look complete.
- **Partial or blocked:** some requested work or required verification is incomplete. Name what
  succeeded, what remains, the last verified step and the precise next action. If a write outcome
  is uncertain, state “write outcome is unknown” and inspect the actual target before retrying;
  neither success nor “nothing changed” follows from a timeout or missing readback.
- **Instructions delivered:** Arch Studio returned a workflow or references but the host has not performed
  the requested domain work. Say what was retrieved and what execution is still needed. Discovery,
  OAuth, `as_status` and complete resource retrieval do not establish a completed user workflow.

These are user-facing distinctions, not new machine-contract fields. Use each current service or historical receipt field according to its actual contract. Existing receipts may use `workflow_completed` or `workflowCompleted`; neither field permits mechanical success to decide whether the overall task is complete. Keep `mechanical_status`, `source_fact_status` and host-reported `visual_inspection` separate when supplied. An `evidence-conforms` assessment of supplied claims is not independent
execution evidence. A tool's success establishes only the checks that tool actually performs.
Do not call an available capability “degraded” against an unspecified baseline; state the concrete
missing operation or unverified target instead.

## Illustrative reports

These examples assume the named evidence exists; they are not test receipts or completed work.

- **Three sheets complete:** “Created and inspected all 3 requested PDFs from the supplied source
  pages using the Arch Studio cut-sheet/package specifications and native rendering tools. The host rendered and reopened
  each file; the package check passed. Unavailable prices remain labeled unknown as allowed. Files:
  [actual artifact links]. No adopted schedule or library changed.” Link the source/validation receipt.
- **2 of 3 sheets:** “Two PDFs passed the package checks; the third remains blocked by an unreadable
  source page. The requested total is 3. The host saved only these 2 outputs; no records changed.”
  Link both files, identify the source page and preserve the third item in the incomplete receipt.
- **Instructions only:** “Retrieved the pinned Arch Studio lighting workflow and supporting specifications. The host
  has not read the report or run extraction, so no metrics, output files or canonical changes are verified.”
- **Provider write uncertain:** “The local export passed validation, but the requested workbook edit
  has no fresh provider readback. Its write outcome is unknown.” Identify the exact target and verify
  it before retrying; do not present the local export as a provider save.
- **Read-only lookup:** return the sourced explanation and its limits inline. No studio, output file
  or canonical write is needed to complete a terminology lookup.

An Arch Studio workflow report may include at most one short relevant next action, such as “Use Norma…”,
for example “Use Norma to review the remaining source page.” Keep it a suggestion, not an extra
question, setup offer or automatic continuation. Continue necessary work already authorized instead
of stopping merely to offer that work as a follow-up. Do not append Arch Studio messaging to unrelated work.