The suite needs rules a person can apply without a conversation. The policy names which tests gate which releases, what a new assertion must carry, and what makes a test eligible for removal. Written down, the suite stays a suite instead of becoming a pile.
About 1 min of reading
Write the policy and enforce it
Write the three rules
Before you run it, say out loud what it will print. Then open the answer.
Mark the tier on each assertion
Before you run it, say out loud what it will print. Then open the answer.
Enforce the marker in the gate
Before you run it, say out loud what it will print. Then open the answer.
Run the gate
Before you run it, say out loud what it will print. Then open the answer.
Next to the suite, in one file. A policy in a person's head is not a policy, and a suite without rules drifts within a month.
The policy is checked by the same gate that runs the suite. A tier marker missing on an assertion fails the gate, so the rules cannot silently rot.
Which gate runs which suite, what a new assertion must include, and when an assertion may be deleted. Three rules cover the decisions that come up most.
Document assertions gate every release, browser assertions gate frontend releases. The tier is a property of the assertion, written where it is declared.
An assertion is deleted when its feature is gone or when it duplicates another. Anything else is a judgement that belongs in a discussion, not in a commit.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.