Gå til hovedinnhold

Tier gates per market

Goal: spend review time where each market needs it. A contractual locale may require a person to approve every block. In a mid-tier market, people review the important strings and the rest ships machine-translated. A long-tail locale ships as soon as its translations pass their checks. Ship gates encode that policy per market in the recipe, and one command, kapi check --ship, enforces all of it. The gate model is the kapi loop; the schema is the project-file reference.

The tiers​

TierPolicyGate
ContractualA person approves every block{ translated: 100, established: 100 }
Mid-tierEverything translated, the important 80% human-reviewed{ translated: 100, established: 80 }
Long tailEverything translated, with its checks green; no person approves{ translated: 100 }

A gate spells the approved rung established: established: 80 asks for at least 80% of blocks approved by a person.

The recipe​

Define the tiers once in the gates: registry, then assign markets with ship_gates: rules; the most specific matching rule wins:

kapi.yaml
version: v1
name: storefront

defaults:
  source_language: en
  target_languages: [de, ja, fr, es, pt-BR, nl, sv]

gates:
  contractual: { translated: 100, established: 100 }
  standard: { translated: 100, established: 80 }
  machine: { translated: 100 }

ship_gates:
  - when: { locales: [de, ja] } # markets with a review contract
    gate: contractual
  - when: { locales: [fr, es] }
    gate: standard
  - gate: machine # everyone else: the long tail

Rules can also select by collection, so regulated content answers to a higher bar in every market: a when: { collections: [Legal] } rule with a established threshold outranks the locale rules for that content because it is evaluated per (collection, locale) and the most specific rule wins.

The machine tier ships what is translated and passes its checks. An agent can pre-review that tail with a score and its reasons, which the review queue shows, but only a person approves a block, so the established tiers always measure people. See who approves a block.

Trade-offs​

  • Review budget goes where the risk is. The contractual tier consumes reviewer time proportional to its content; the long tail consumes none. A market moves tiers by moving one line in the recipe, and the change is reviewed in git diff like any policy change.
  • The mid-tier percentage is a floor. established: 80 says at least 80%; it does not choose which 80%. Reviewers work the worklist (kapi status --review) in whatever order matters; the gate only measures the outcome.
  • Source drift affects each tier differently. An edited source string re-opens its blocks in every locale; the contractual tier then waits for a person while the machine tier recovers on the next kapi up pass; see drift, watched end to end.

In CI​

kapi check --ship evaluates every scope against its own tier and exits 3 when any gate is unmet, so one job enforces the whole strategy:

kapi check --ship               # every market against its tier
kapi check --ship --locale de   # scope to one market
kapi check --ship --json        # structured result for a job summary

One step comes first on a runner. established thresholds read their decisions from the project store, which starts empty on a fresh machine, so kapi store import reads the repository's context files in before the gate runs. Nothing else is needed, since gate evaluation makes no provider calls. The workflow wiring is Ship gates & CI.

Next​