A result deserves
a clear trail.
Useful engineering distinguishes source identified, implemented, connected, deployed, executed and independently verified. Each state requires its own evidence. A research proposal defines an idea; it does not establish these capability states.
| State | What it establishes | Required evidence |
|---|---|---|
| Source identified | The relevant source object and its provenance are known. | Repository or document identity, path, revision and attribution. |
| Implemented | The mechanism exists in a specific source revision. | Implementation, build inputs and scoped test results. |
| Connected | The required adapter or service binding has been observed. | Authenticated transport checks and dependency identity. This does not prove workload completion. |
| Deployed | The intended release is present at the target. | Deployment identity, destination and revision readback. |
| Executed | An authorised workload ran and its outcome was observed. | Actor, authority, target, inputs, execution record and result readback. |
| Independently verified | A separate reviewer assessed a declared scope against criteria. | Reviewer identity, evidence references, findings and assessment record. |
No PASS without evidence.
An unavailable capability must remain an explicit pending, blocked or failed state. The worker does not award its own independent verification result.
A native Sites deployment receipt concerns website delivery. It does not certify the whole BRAINK estate, its hardware or every proposed integration.
The result comes
with its evidence.
Keep the scope, source revision, verification results and operating limits together. A design requirement, a passing test and a production deployment establish different things.
Read the release record.
The website delivery record identifies the implemented journeys, verification scope and remaining limits. It records author execution; independent assessment is a separate result.
Download the website delivery recordKnow how to recover.
Retain unsent enquiry drafts on the page during validation errors. Explain unavailable tools. For a failed release, restore a previously saved Site version rather than rewriting deployment history.
Inspect the required release fieldsStart with what needs to work better.
Bring a process, an idea or a systems question. We’ll help define the next useful step.