Conflict Register¶
Tracking register — instantiates Alignment Governance and Dispute Resolution
A living ledger of every raised misalignment and its lifecycle — one row per dispute tracked to closure, with recurrence flagged and resolved cases retained as searchable precedent.
A Conflict Register is the governance system's memory: a single ledger with one row per dispute, tracking status, owner, forum, resolution, and how many times the same conflict has come back. Its defining trait is the longitudinal, whole-caseload view — it is not the entry form for one dispute and not the ruling on one dispute, but the standing record that watches every dispute from the moment it is opened until it is closed, verified, and filed. Two jobs live here that no single-case artifact can do: closing the loop (nothing raised is allowed to silently die; open items have owners and due dates, and stalled ones surface) and turning history into precedent (once a dispute is resolved, its outcome joins a searchable body the system can point to the next time a like case appears). The register is where a governance body learns that it is having the same fight for the fourth time.
Example¶
A large university's college of arts and sciences maintains a Conflict Register for departmental and program governance disputes. Each row is a case: a cross-listing turf fight between two departments, a disagreement over who controls a shared teaching lab, a grievance about how graduate funding lines were allocated. The columns that matter are status (open / in forum / decided / implementing / closed), owner, resolving forum, decision link, implementation due date, and reopen count.
The register earns its keep in two moments. First, at follow-through: the lab-control dispute was "decided" three months ago, but its row still shows implementing — overdue, because the promised shared-scheduling system never launched; the register makes that visible so the dispute does not quietly reopen as a fresh fight. Second, at recurrence: when a third department files over cross-listing revenue, the associate dean filters the register, finds two prior cross-listing cases with a reopen count of 2 apiece, and sees the pattern — this is not three disputes but one unresolved policy gap. The register did not decide any of these; it made the caseload legible over time and told the college where its rules, not its cases, needed fixing.
How it works¶
The register's method is disciplined bookkeeping with two active behaviors layered on a passive log. The passive layer is the row itself, updated as a case moves through the pathway. The first active behavior is follow-through enforcement: every non-closed row carries an owner and a next-check date, and the register surfaces anything past due or stuck between states, so "decided" cannot masquerade as "done."[n1] The second is recurrence detection: cases are tagged so that a new filing can be matched against closed ones, and a rising reopen count is treated as a signal that the underlying alignment problem — goals, incentives, decision rights, or rules — needs to change rather than that another case needs deciding. The distinctive discipline is retention hygiene: resolved rows are kept, indexed, and made searchable, because a register that discards closed cases keeps no precedent and re-litigates from scratch.
Tuning parameters¶
- Row granularity — whether related grievances are logged as one case or many. Splitting shows detail but hides patterns; merging reveals recurrence but can bury a distinct sub-dispute.
- Follow-through strictness — how aggressively overdue items are surfaced and to whom. Tight tracking prevents silent death but can nag owners into gaming the status field.
- Retention depth — how far back closed cases are kept searchable. Long retention builds richer precedent; it also lets stale, context-free outcomes be cited as if binding.
- Recurrence threshold — how many reopens trip a "fix the system, not the case" flag. A low threshold catches drift early but raises false alarms on genuinely distinct cases.
When it helps, and when it misleads¶
Its strength is that it defeats the two quiet failures of case-by-case governance: disputes that are "resolved" but never implemented, and disputes that recur because nobody noticed they were the same. By holding the whole caseload over time, the register converts scattered incidents into a learnable pattern and gives follow-through an owner and a deadline.
It misleads when the log is mistaken for the work — a tidy register with every row green can coexist with festering conflicts if owners update status to look compliant rather than to reflect reality (status theater). Stored outcomes can also harden into precedent drift, where an old case is cited to settle a new one whose material facts differ, mechanizing consistency into unfairness. The guard is to periodically audit a sample of "closed" rows against reality, and to treat retained cases as reference, not rule — precedent informs a fresh decision, it does not replace one.
How it implements the components¶
follow_through_loop— the register is where implementation is owned and checked: every decided case stays live until its obligations are verified done, and stalled ones are surfaced rather than forgotten.precedent_library— the retained, searchable body of resolved cases is the precedent library, letting the system handle like disputes consistently and detect recurrence.
It tracks and remembers cases but does NOT capture a single dispute's entry fields or check standing at filing (misalignment_intake_channel, stakeholder_standing_model — that is the Dispute Intake Form, its nearest twin: the form opens one case, the register watches them all). Nor does it write the reasoned ruling for any case (decision_record — Ruling or Decision Memo).
Related¶
- Instantiates: Alignment Governance and Dispute Resolution — supplies the follow-through and precedent memory the pathway relies on.
- Consumes: Dispute Intake Form — completed intakes become the register's rows; Ruling or Decision Memo — closed rulings become its precedent entries.
- Sibling mechanisms: Dispute Intake Form · Escalation Threshold Table · Governance Cadence Meeting · Review Board or Panel · Ruling or Decision Memo · Decision-Rights Matrix · Mediation Session Protocol
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: A living ledger of every raised misalignment and its lifecycle — one row per dispute tracked to closure, with recurrence flagged and resolved cases retained as searchable precedent, making its operative form a durable record, ledger, register, or trace whose value depends on preserving actual state or history.
Independent corroboration: The frozen evidence defines Conflict Register as 'A living ledger of every raised misalignment and its lifecycle — one row per dispute tracked to closure, with recurrence flagged and resolved cases retained as searchable precedent', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Project and issue-management practice cohered standing registers with owner, status, due date, closure, recurrence, and retained history.
Related originating lineages:
- Law & Governance — Dispute administration contributes forum, precedent, appeal, and verified settlement records.
Review resolution: Both reviewers agree on organizational_management as primary. Reading the source mechanism confirms that its defining operation belongs to that lineage; the final record retains law_governance only where it materially formed the mechanism and keeps present-day application breadth separate from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] The pattern is borrowed from the risk register of project management — a standing table where each risk carries an owner, status, and review date so that nothing tracked is allowed to fall silently off the list. A conflict register applies the same open-item discipline to disputes. ↩