# Govern the interface

Define the request, evidence, owner and escalation trigger for dependencies that should remain.

Duration: 6 min

Necessary dependencies need explicit service and decision expectations.

## scale-value-flow-m1-l3-reading

### Specify what must remain separate

Use an authored five-field interface record for each necessary dependency: the request the delivery team makes, evidence the specialist needs, expected response, decision owner and escalation trigger. Name exceptions and the conditions under which urgent work can take another route.

Review repeated exceptions. A recurring exception is a trigger to revisit the boundary or service expectation. A rare, high-consequence review may be exactly the dependency governance should preserve.

Only after this diagnosis should leaders add cross-team planning or portfolio coordination. The mechanism should serve a necessary shared constraint or decision—not mirror a reporting layer.

**Failure mode:** measuring specialist use instead of whether outcomes move safely and learn quickly.

### Worked example and transfer practice

All examples below are fictional teaching material. Use synthetic notes; no workplace or personal data is required or uploaded.

**An interface that supports a real response.** A fictional shared platform needs a change request, test evidence and rollback instructions. The platform owner agrees a response expectation and an escalation route for a missed checkpoint. An urgent path still requires authorised risk acceptance; it does not bypass mandatory assurance. Repeated urgent requests trigger review of capacity, preparation or the boundary itself.

**Try before reading the guide:** Write the five-field interface record for independent safety review: request, required evidence, response expectation, decision owner and escalation trigger. State who can authorise an exception and which safeguards cannot be waived.

<details>
<summary>Practice review guide</summary>

Both sides can tell what to prepare and what happens next. A response expectation is an operational agreement, not a guarantee invented by the requesting team. Status colors or meeting frequency alone do not create authority.

</details>

## scale-value-flow-m1-l3-check

Public answer keys are intentional.