A change should come
with a reason to trust it.

01 / Define the evidence

Agree on “works”
before building.

An acceptance criterion describes an observable result. It should identify the starting condition, the action, the expected outcome, and what happens when a dependency fails.

The same discipline applies to an integration, a device workflow, or an AI-assisted task. The examples and failure conditions change with the work.

02 / Work that can be inspected

Make the change
visible before release.

• Trace the intent. Record what the business asked for, the agreed scope, and the assumptions behind the implementation.
• Review the implementation. Keep the source and configuration changes available to the people responsible for review.
• Check representative cases. Test the normal path, important edge cases, and relevant failures. Record what was not tested.
• Approve the release. Name the approver, the release window when needed, and the signals that would trigger a rollback or stop.

A passing test suite is evidence about the cases it covers. It is not proof of universal reliability.

03 / AI with a defined role

Choose the task.
Then choose the model.

Before using a model in a workflow, define the information it may access, the output it should produce, and how that output will be checked. Evaluate it on examples that resemble the real work, including cases where the correct response is to stop or ask for help.

Separate provider-specific code from the surrounding business rules where practical. Changing models still requires evaluation: different providers, versions, and prompts can behave differently.

For consequential changes, the system should present the proposal and supporting evidence to a named human approver. The model does not decide its own permissions.

04 / A live, bounded example

The inquiry you can
use on this site.

This website includes a deployed inquiry workflow. It is a small example of the separation between a visitor’s intent, durable storage, and notification.

1. 01Compose

   Type, dictate where supported, or import a text brief locally. Review the editable draft.

2. 02Validate

   The service checks submitted fields and applies basic request limits.

3. 03Record

   The brief is stored before a notification is attempted. A request identifier supports safe retries.

4. 04Notify

   The service requests an email notification and records whether the email provider accepted it.

The site is served over HTTPS from a private AWS storage origin through CloudFront. Inquiry records use DynamoDB. Notification failure can leave a stored inquiry needing follow-up; it does not erase the record.

This demonstrates a bounded workflow, not the production capacity or reliability of a future client system. That system needs its own requirements and verification.

05 / Ownership in practice

Know how to operate it.
Know how to leave.

Account ownership, source access, credentials, documentation, backups, and recovery responsibilities need explicit owners. They are part of the engineering plan, not an assumption made at handoff.

Before production, agree on monitoring, support coverage, recovery expectations, and the limits of any automation. Regulated or sensitive workloads require a specific review of their data and access requirements; using a cloud provider does not by itself establish compliance.

For a serious evaluation, ask to see a relevant walkthrough and the evidence behind its claims. Client names, systems, and results are shared only with permission.