The Multi-Site Conformance Build Standard

1. What this standard covers

Any business running the same operating process in more than one place under more than one manager. Franchise networks, branch networks, multi-entity groups, and any business where a region has enough autonomy to choose its own tools. It sits above the other standards rather than beside them: you implement a compliance calendar or a rejected pack first, and this is how that survives being deployed to fourteen places.

The failure it prevents is not non-compliance. It is invisibility. A branch working entirely outside the system looks identical, on every report the centre has, to a branch with nothing happening, and both look better than a branch that is honestly recording its problems.

2. The objects, and what is in them

Three objects on top of whatever the underlying standard already defines. The key contract is the one that has to be written down and versioned, because an unwritten convention is what forks.

Segment
  - segment_id, name, kind (branch | franchise | region | entity)
  - group (the access group that grants membership)
  - owner (a named person), coach (a named person)
  - onboarded_on, thresholds

KeyContract
  - version, effective_from
  - required_keys        [the identifiers every record carries]
  - required_fields      [per record type]
  - closed_lists         [field -> permitted values]
  - extension_rule       "add freely, never rename or fork"

DriftFinding
  - id, segment_id, detected_on
  - kind (schema | gate_bypass | shadow_register | silence)
  - record_ref, detail
  - status (open | accepted | resolved)
  - owner, resolved_on

A DriftFinding with status accepted is important and is not the same as resolved. Some local variation is legitimate, and recording that a person looked at it and decided it was fine is what stops the same finding being re-raised every week until everybody ignores the report.

3. The checks, in order

The contract comes first because every later check is a comparison against it, and onboarding comes last because a segment that takes real records before its gates are live starts with drift already in it.

1. Define the key contract: the small set of identifiers and required fields every segment must carry, written down once and versioned.
2. Let segments add, never rename or fork, and enforce that at validation rather than by asking. An extra column is local colour. A renamed key is a second system.
3. Give every record a segment, from group membership rather than a typed label, so ownership cannot drift from access.
4. Run the drift check on a schedule, covering all four kinds: schema drift, gate bypass, shadow register and silence. Detecting only the loud two is the common partial build.
5. Score each segment on the same measures the centre uses. One definition, computed once, read by everybody.
6. Publish the report on schedule regardless of the numbers. A quiet period still publishes, saying so, because its absence must never become the signal.
7. Let each segment see its own findings at the same detail the centre sees. A centre-only report is surveillance, not feedback.
8. Route a segment past a threshold to a named person, not to another all-branch email.
9. Onboard a new segment with the gates already live, before it takes its first real record.
10. Make sure it survives the builder: someone else can explain it, and it runs on an account the business owns.
11. Run the pass test below, in production, not on a stub.

4. Four kinds of drift

They fail differently and they need different detection. The third and fourth are the ones that hide, because both look like a quiet branch.

The shadow register is the expensive one. It usually starts as a reasonable local workaround during a busy fortnight, and the tell is not a complaint but a rhythm: nothing for days, then twenty records entered in an hour. By the time anybody notices, the local file has months of decisions in it that the system never saw.

5. One score, computed once

Give each segment a conformance score built from the gates the underlying standards already define: the share of dates derived rather than typed, work closed with evidence bound, contacts made after a suppression check, obligations with a live future date, and queues acknowledged inside their thresholds.

Weight them however suits the business, but compute them in one place. The moment two segments can produce their own version of the same measure, the weekly conversation stops being about the work and becomes about whose number is right, and that argument is unwinnable and permanent.

Show the centre every segment and show a segment itself plus the distribution it sits in. A branch that can see it is fourth of fourteen behaves differently from one told only that it is below target, and the difference costs nothing to provide.

6. Training is not a control

Most networks respond to drift with material: a new module, a refreshed procedure, a session at conference. All of that is worth doing and none of it is a control, because a control is something that detects or prevents. Material only works on people who were going to comply anyway.

The controls in this standard are the shared keys, which prevent, and the drift report, which detects. Everything else is support. When a segment crosses a threshold, the response is a named person having a conversation with a named person. An email to all branches about a problem two of them have is how the rest learn to stop reading.

Publish on a fixed schedule regardless of the numbers. A report that appears when things are good and goes quiet when they are not teaches everybody to read its absence, and at that point you have built a signal you cannot turn off and cannot use.

7. What stays with a person

• ✓Accepting a local variation as legitimate, and recording why.
• ✓Deciding the key contract needs to change, which is a version bump and not an edit.
• ✓Every conversation with a segment that has crossed a threshold.
• ✓Judging whether a low score is a compliance problem or an honest branch recording its problems where a quieter one is hiding them.
• ✓Onboarding, and the decision that a new segment is ready to take real records.

The fourth is the one that decides whether this standard helps or harms. A scoring system that punishes honest recording will get clean numbers within two months and will have destroyed the only instrument you had.

8. Provider: what to stub, and what not to hand-roll

This is a build on top of whatever you already run. The only thing worth buying here is the identity you almost certainly already own.

provider:
  stub:       local.mock_sites
  production: none                       # no hosted step; runs on your own systems

stub in development
  - two segments, one deliberately misconfigured
  - the drift check run by hand
  - a printed report instead of a posted one

build it on what you already run
  - membership and access: your existing identity provider.
    Group membership, never a typed segment label.
  - detection and scoring: your own queries. Ordinary build.
  - the report surface: wherever the segments already work.
  - the coach on each threshold: a person. No product.

do not hand-roll
  - the key contract as an unwritten convention. Write it
    down and version it, or the first busy fortnight forks it.

There is no product for this standard and we do not know of a credible one. Franchise and multi-site platforms generally solve reporting, which is the half you get free once the keys hold, and are silent on drift detection, which is the half that is hard.

9. Conformance checklist

Hold a DIY build or a vendor to this. If a box is empty, it is not in production.

• ✓1. The key contract is written down and versioned. Not an unwritten convention or a diagram in an onboarding deck.
• ✓2. Segments can add fields and cannot rename or fork keys. Enforced by validation, not by asking.
• ✓3. Segment membership comes from an access group. Not a label somebody types into a record or a report.
• ✓4. Drift is detected on a schedule, covering all four kinds. Including the two that look like a quiet branch.
• ✓5. One definition of every measure, computed once. No segment can produce its own version of the same number.
• ✓6. The report publishes on schedule regardless of the numbers. Its absence never becomes the signal.
• ✓7. Each segment sees its own report. Not only the centre. Same findings, same detail.
• ✓8. A threshold routes to a named person. Not to an all-branch email.
• ✓9. A new segment's gates are live before its first real record. Onboarding does not start with drift already in the data.
• ✓10. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
• ✓11. The pass test passes. Break one segment's contract and bypass a gate, and both appear in that segment's own report; rename a key and validation refuses it; let a period pass with nothing to report and the report still publishes on time.