Why a release can look green while its dependencies are broken

A green status answers a smaller question.

An engineering team can finish its work while the release still depends on an agreement nobody has checked. The application is built. The infrastructure change is tested. Security has approved the scope. Each update is accurate. Whether those pieces can come together on the promised date is a separate question.

A useful release review makes the conditions behind the status visible: what must be available, who provides it, when it is needed and what evidence supports the agreement. That gives a leader something more actionable than another round of “still on track?”

The approach below is a coordination check. Keep your technical release criteria alongside it, including testing, observability and recovery. Google's work on reliable product launches describes both cross-team coordination and a carefully maintained launch checklist. A useful review needs to fit the release and stay manageable.

Three green updates. One missing agreement.

Consider a fictional launch, Harbour. A customer asks to go live on Friday instead of the following Monday. The application team can meet the new date, and the approved release scope is unchanged.

The missing agreement is Platform's deployment slot. “Complete” refers to preparing the change. Its production slot is still Monday, following the original plan. The new customer date hasn't changed that booking.

On Tuesday, there are options. Platform can offer a Thursday morning slot if capacity is agreed by Wednesday at 10:00. Application can then verify the production configuration on Thursday afternoon. By Friday, the same discovery would leave much less room to respond.

The dependency was visible in the relationship between the records: the customer commitment, Platform's schedule and Application's acceptance check. Reviewing each team's progress independently missed it.

Describe the condition that lets the next team proceed.

Turn “we depend on Platform” into an agreement someone can confirm:

Platform will apply configuration version 3 in production by Thursday at 12:00, so Application can complete its acceptance check by 17:00.

That sentence names a provider, a deliverable, an environment, a deadline and a consumer. It also exposes the handoff: Platform can finish its action before Application has established that the result meets the release's needs.

For each dependency that could change the release decision, record:

• The required condition. Specify the scope and how the consumer will accept it.
• Both owners. Name who provides the outcome and who can confirm it is usable.
• Both dates. Keep the consumer's need-by time separate from the provider's agreed time.
• The evidence. Link the relevant booking, approval, implementation or owner confirmation. Include when it was checked.
• The open question. State exactly what remains unresolved and who will check it next.

Use the release dependency map template to capture these records. Begin with the few dependencies capable of changing the date, scope or go/no-go decision. Keeping that set small makes it easier to maintain.

Work backwards to the decision deadline.

The release date is the end of a chain. The useful intervention point may be several steps earlier. Ask what time the consumer needs the result, how long acceptance takes, and how much notice the provider needs to commit.

These are agreed times in the example, not a forecasting formula. In a real release, ask the owners about lead times and uncertainty. Include room for the failures you need to recover from, and make that allowance explicit.

Put a decision deadline next to each unresolved dependency. If confirmation hasn't arrived by that time, the release owner needs to choose an alternative: secure capacity, reduce scope where feasible, or renegotiate the date. A next check is useful only if someone knows what happens when it fails.

Let changes reopen the relevant questions.

A confirmation applies to a particular situation. It can stop being useful before it becomes old. An approval from yesterday may cover the wrong scope; an unchanged agreement from last week may still be perfectly valid.

Record the conditions that would require a new check:

The date moves

Recheck provider capacity, lead times and the order of handoffs.

The scope changes

Recheck acceptance criteria and which approvals cover the new work.

An owner or allocation changes

Reconfirm responsibility and the time available to deliver.

Records disagree

Ask the accountable owner which agreement holds and which record needs updating.

Use the source that can establish the particular claim. A merged pull request establishes a code change. A deployment record helps establish what is running. An owner can confirm an allocation. A Slack summary of those records doesn't automatically establish all three.

When context is missing, ask a narrow question: “Is configuration version 3 booked for production by Thursday at 12:00? The deployment schedule still shows Monday.” The owner can resolve a specific discrepancy without reconstructing the whole release.

Run a review that ends in a decision.

Bring the release owner and the owners of the unresolved dependencies together, or resolve the questions asynchronously if there is time. Work through the actual disagreements:

1. Restate the commitment. Confirm the customer, scope, date and acceptance criteria everybody is using.
2. Inspect the uncertain conditions. Separate missing evidence, a confirmed conflict and work that is still ahead.
3. Choose the next action. Name the decision maker, the trade-off and the latest useful time to decide.
4. Verify the resulting agreement. Check that the affected plans and owners reflect the decision.

For Harbour, booking Thursday's slot is one outcome. Applying the configuration and passing the acceptance check are later outcomes. Keep those distinctions visible so the first successful action doesn't prematurely close the whole dependency.

Carry the useful lesson into the next release.

Afterwards, ask what would have made the dependency visible sooner. In Harbour's case, moving the customer date should trigger a check of production bookings and the time needed for acceptance. That is a specific improvement to the next release process.

Keep the context around the decision too. Platform could offer Thursday in this example. It may not be able to next time. The reusable lesson is the relationship and the question to ask early.

This is the kind of organisational context Ocula is designed to connect: spot a changed commitment, verify the affected dependencies, coordinate permitted actions and check their outcomes. The release coordination example shows how that loop fits together.

For your next release, start with one change: ask every team which external condition its green status assumes. Then check the agreement behind the most consequential answer.