> For the complete documentation index, see [llms.txt](https://dsg-3.gitbook.io/dsg-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dsg-3.gitbook.io/dsg-docs/cinema-proof-agent/runtime-and-integrations/truth-boundaries.md).

# Truth Boundaries

Claims Cinema can support, claims that need fresh evidence, and rules that prevent configuration from being presented as execution proof.

Cinema documentation follows an evidence-first hierarchy:

```
current live execution + exact deployment identity + persisted evidence
        >
current CI / production workflow evidence
        >
repository configuration and source
        >
historical documentation
```

## Do not overstate these claims

Do not claim any of the following without evidence for that specific statement:

* current production uptime;
* every integration is connected and healthy;
* every Agent action is safe or approved;
* production deployment passed merely because source exists;
* a configuration file proves a live environment is configured;
* Z3 feasibility proves legal correctness or global correctness outside the encoded problem;
* certification, SOC 2, ISO, PDPA, or other third-party compliance status without issuer/scope/audit evidence;
* replay performed a new production action.

## What a successful workflow proves

A passed workflow proves the checks and execution represented by that workflow at that time and identity. It does not automatically prove a different commit, later runtime state, or unrelated third-party service.

## What source code proves

Source code can prove implementation intent and exact logic. It does not prove that production executed that code successfully unless deployment/runtime evidence links the source identity to production.

## What the UI must show

Before evidence exists, use explicit states such as pending, waiting, disconnected, blocked, failed, review, or unverified. Do not pre-render `PASS`, `SUCCESS`, or `VERIFIED` as decorative defaults.

The product should make the next action clear: what failed, why it failed, what evidence is missing, and what must happen next.