Changes

A change is a versioned change to your source that lands on trunk. It is the unit humans review.

What a change carries

Underneath, it is a commit and a diff. The platform's contribution is what it attaches:

• Intent—what it is trying to accomplish, in business terms. “Auto-approve refunds under $50 for customers in good standing.”
• The diff—what it actually does to the code.
• Evidence—tests, evaluation results, and a simulation against real historical data showing what would have been decided differently.
• A preview—an ephemeral environment running exactly this change.
• State—proposed, under review, landed, reverted.

The reviewer reads the intent and the evidence, and the diff is there when they want it. The order matters. Nobody reviews forty cold diffs a week. Forty statements of intent with evidence attached is manageable, and you go deep on the two that look wrong.

Why change and environment must come apart

Git's model—a branch is a line of work—was built for humans making a handful of changes. It conflates a line of work with a place to run it, which does not survive agents proposing work continuously:

• An environment is a real database. You cannot have hundreds.
• A change that is only proposed should cost nothing.
• Nobody wants to review branches. They want to review changes to the business.

So a change is cheap and numerous. An environment is a long-lived named instance with its own data—productionalways exists, and you may have staging or a pilot serving real customers. Environments are few.

A change's preview is ephemeral and disappears when the change closes. Landing on trunk is what promotes it toward production.

Gates

A gate is the policy that decides whether a change may proceed. The policy is versioned with the project and may require tests, evaluations, or human approval.

Loosen the gate where the system has earned it and keep it tight where the blast radius is real. Because the gate is code, loosening it is itself a change someone reviews.

What landing produces

A landed change may become part of an immutable release containing the backend and app builds, migrations, dependency versions, and compatibility metadata resolved from one source revision. An environment records the exact release it runs.