Contributor and Editorial Governance

The page was approved yesterday. Is today's revision approved?

A contributor drafts a course page. An editor approves revision R7. The contributor then changes the assessment answer and evidence text, producing revision R8, but the publishing queue still carries the approval attached to R7. If the platform stores only approved=true, it has lost the fact that the approval and the content no longer identify the same artifact.

In this lesson you build Contributor Editorial Governance Matrix & Revision Approval Ledger v1. It keeps object identity, revision/change hashes, contributor/reviewer/editor/publisher identities, authority scope, review count, owner-review requirement, conflict/recusal state, exceptions, provenance, review comments, publish-gate state, rollback reference, and audit event identity as separate evidence.

Core rule: permission to contribute is not permission to approve; approval of one revision is not approval of a later revision; publication is a bounded human-governed decision over visible evidence.

For: learning-platform engineers, CMS designers, editorial operations teams, QA reviewers, and governance owners. Not for: granting a user hidden authority, letting AI approve production content, treating a prior approval as transferable across material revisions, or using GitHub mechanics as MAKNOW policy authority.

Route orientation and ownership boundary

MKN-021 owns only Contributor and Editorial Governance. Its frozen prerequisite is MKN-001. MKN-020 owns learning/product analytics event taxonomy; MKN-022 owns Web Push and Email Notification Delivery. This lesson does not absorb either adjacent outcome.

Foundation learners use a role-capability field map and one guided stale-approval case. Repair learners isolate the first broken governance dimension and rerun only the affected gate. Experienced learners defend materiality, recusal, exception, and rollback choices without collapsing them into a single trust score.

Checkpoints: F1 state the ownership boundary and one non-goal; F2 diagnose why R7 approval cannot authorize R8; F3 recompute authority when a volunteer contributor becomes a paid editor without carrying old self-review privileges or approvals forward.

Mental model: contribution → revision identity → reviewer assignment → conflict check → revision-bound review → publish gate

Use this ordered flow:

draft contribution → content/revision/change hashes → capability + object scope → reviewer assignment → conflict/recusal → revision-bound review → editorial approval → publisher gate → publish/hold → rollback/audit

Any material edit after review creates a new review object. It may inherit history, but it does not inherit authority silently. The old approval becomes evidence about an older entity; it is not a magical property of the document name.

Treat the governance record as a ledger of typed facts rather than a mutable approved flag. A revision can be DRAFT, REVIEW_REQUIRED, HOLD_STALE_APPROVAL, HOLD_CONFLICT, HOLD_EXCEPTION_EXPIRED, PUBLISH_REVIEW_REQUIRED, or another explicit non-success state. The state should say why the gate cannot advance.

Foundation contract: bind every authority decision to an exact object and revision

The frozen critical dimensions are: content_object_id, revision_hash, change_set_hash, contributor_ref, reviewer_ref, editor_ref, publisher_ref, authority_scope, approval_state, approval_revision, stale_approval, required_review_count, owner_review_required, conflict_of_interest_state, recusal_state, exception_ref, exception_expiry, provenance_entity, provenance_activity, provenance_agent, review_comment_ref, publish_gate_state, rollback_ref, and audit_event_id.

Minimum invariants:

1. A capability is scoped to a role and an object or object class. Role names alone are insufficient authority.
2. The approved revision must equal the revision entering the publish gate. A material change invalidates or stales prior approval according to local policy.
3. The contributor cannot silently become the only reviewer of their own material change. Conflict and recusal are first-class states.
4. Required review count and owner/code-owner-style review requirements are checked from current evidence, not from a historical badge or relationship.
5. Exceptions are explicit, time-bounded, attributable, and narrow. An expired exception cannot authorize publication.
6. Provenance records the content entity, the activity that created/reviewed it, and the responsible agent. Missing provenance is not repaired by guessing.
7. The publish gate does not mutate review evidence. It evaluates it. Rollback and audit references remain available after publication.
8. AI may organize or validate supplied evidence, but it may not grant approval, recusal, exception, or publishing authority.

Deep explanation: provenance and review controls solve different halves of the problem

W3C PROV. The PROV family models provenance around entities, activities, and agents. That gives us a vocabulary for saying: revision R8 is an entity; the edit or review is an activity; the contributor or reviewer is an agent; and attribution/derivation links explain how the artifact came to exist. PROV is valuable because it preserves traceability across revisions. It does not define MAKNOW's reviewer roles, minimum approval count, materiality threshold, or who may press Publish.

GitHub review/ruleset controls. Current GitHub rulesets can require approving reviews, require review from code owners, require approval from someone other than the most recent pusher, and dismiss stale approvals when changes alter the reviewed diff. These mechanics demonstrate an important operational pattern: the thing approved is a particular state of a change, and later changes can invalidate that approval. GitHub remains an implementation example, not the editorial constitution for a learning platform.

MAKNOW inference. Combining provenance with revision-aware review controls supports a strong governance inference: approval should be revision-scoped and auditable. If the reviewed evidence changes materially, the platform should preserve the old approval as history but stop treating it as authority for the new revision.

MAKNOW design authority. Role names, capability matrix, object scope, conflict categories, recusal procedure, required-review count, exception approver, exception duration, material-change rule, final publisher role, and rollback policy are local design decisions. External documents cannot silently decide them.

Worked examples

Example A — R7 was approved; R8 changed assessment evidence

Object COURSE-PAGE-17 has revision_hash=R8-HASH. The ledger shows approval_revision=R7-HASH. The change_set_hash for R8 includes an assessment-answer change and updated evidence text. Regardless of who made the edit, the exact approved entity is no longer the current entity.

Correct result: stale_approval=true and HOLD_STALE_APPROVAL. Preserve the R7 review comment and provenance; create a new review activity for R8; do not overwrite history to make the ledger look current.

Example B — contributor is also the sole reviewer while conflict is active

Contributor AGENT-A edits a lesson they own and is assigned as the only reviewer. conflict_of_interest_state=ACTIVE, recusal_state=NOT_RECUSED, and no explicit bounded exception exists. A high reputation score or a long contribution history does not neutralize the conflict.

Correct result: HOLD_CONFLICT_REVIEW. Route to an eligible reviewer, record recusal, and keep the original contributor attribution. If local policy permits an emergency exception, it must have a named authority, expiry, and audit event; the exception itself becomes evidence to review.

Example C — a valid current revision reaches the publisher gate

R8 has independent current review, required review count is satisfied, owner review is present where required, conflict state is clear, no stale exception exists, provenance is complete, and rollback/audit references exist. The system can reach PUBLISH_REVIEW_REQUIRED.

That state deliberately stops short of auto-publication. The deterministic gate proves that the evidence package is sufficient for the authorized publisher to decide. It does not impersonate the publisher.

Failure modes that create false confidence

• approved=true without approval_revision. The platform cannot prove what was reviewed.
• Role implies global authority. A person promoted to editor is treated as editor for every object without object-scope recomputation.
• Self-review hidden as workflow convenience. Contributor and reviewer resolve to the same agent while the conflict field is absent.
• Approval survives material edit. R7 comments remain visible, so the UI incorrectly lets R8 inherit the positive state.
• Expired exception remains active. Emergency authority becomes a permanent bypass because expiry is not evaluated.
• Review count without reviewer eligibility. Two approvals exist, but both are from agents outside the required authority scope.
• Owner review omitted. A sensitive object requiring designated-owner review passes on general approval count alone.
• Provenance reduced to username. The system cannot link entity, activity, and agent or reconstruct derivation.
• AI recommendation promoted to approval. A model labels the content safe and the platform records that as human editorial authority.
• Rollback omitted. Publication history is auditable only while nothing goes wrong.

Alternatives and trade-offs

Dismiss every approval after any change vs material-change rules. Dismissing everything is simple and safer but increases review load for trivial edits. A materiality classifier is more efficient but requires deterministic fields, conservative defaults, and an escalation path when classification is uncertain.

Strict separation of duties vs bounded exceptions. Strict separation makes authority easier to reason about but can block small teams during incidents. Bounded exceptions preserve operability only if they are narrow, attributed, time-limited, visible to later reviewers, and never converted into normal authority.

Central publisher vs distributed publishing rights. A central publisher simplifies accountability; distributed publishing can reduce queue time. If distributed, the object scope and capability snapshot must be explicit so a broad role does not become unbounded authority.

Mutable status row vs append-only ledger. A mutable row is easy to query but can erase why the state changed. An append-oriented decision ledger costs more storage and operational discipline but preserves review, revocation, recusal, exception, and rollback history. A practical system can maintain a current projection derived from an immutable-enough event history.

Experienced bridge: treat editorial governance as authorization over versioned evidence

In a mature platform, governance is not merely CMS permissions. It is an authorization problem over versioned evidence. The role service says what capabilities an agent may have; the object policy narrows where they apply; the revision ledger says which bytes or semantic revision were reviewed; provenance says who performed each activity; the conflict service can invalidate reviewer eligibility; and the publisher gate combines these facts without rewriting them.

Useful observability separates: contribution created, revision changed, reviewer assigned, conflict detected, recusal completed, review submitted, approval staled, exception granted/expired, owner review satisfied, publish gate evaluated, publication authorized, publication executed, rollback requested, and rollback completed. A single “approved content count” hides the states needed to investigate governance failures.

Guided and independent practice

Guided pass. Open lab://MKN-021/MKN-021-LAB1. Start with the baseline stale-revision fixture. Populate the governance matrix from the visible fields. Identify the first blocking invariant. Explain why preserving the old R7 approval as provenance is different from using it to authorize R8.

Then repair the fixture by binding approval to the current revision, satisfying current review count, owner review, conflict/recusal and provenance fields. The deterministic result should advance only to PUBLISH_REVIEW_REQUIRED, never directly to PUBLISHED.

Independent pass. Diagnose three mutations without copying the baseline answer: (1) self-review under an active conflict, (2) an exception that expired before publish, and (3) a role change whose capability snapshot was not recomputed. For each, name the invalidated field, resulting typed state, minimum repair, and evidence that must remain in the audit trail.

Experienced extension. Propose a material-change taxonomy with at least one case that always invalidates approval, one case that may preserve approval, and one uncertain case that routes to review. Do not hide the local-design nature of that taxonomy.

Verification and evidence

The primary evidence artifact is MKN-021-T1 — Contributor Editorial Governance Matrix & Revision Approval Ledger v1. It contains three auditable scenarios: the stale R8 baseline, a repaired current revision, and the role-change transfer case. The executable lab provides the same evidence as JSON and runs deterministic gates.

Verification requires:

• all 24 frozen critical dimensions remain visible;
• approval_revision is compared to the exact current revision_hash;
• stale approval, conflict/recusal, exception expiry, review count and owner-review requirements are evaluated independently;
• provenance entity/activity/agent fields are present before a positive gate;
• rollback and audit event identity are present before the publisher decision;
• missing evidence yields HOLD or REVIEW_REQUIRED, never invented authority;
• transfer recomputes capabilities from current role and object scope instead of reusing baseline labels.

The lab's deterministic oracle is the frozen evidence contract plus visible fixture values—not model reasoning.

Assessment and transfer gate

S1 — retrieval. Explain the owned boundary of Contributor and Editorial Governance and name one adjacent non-goal. S2 — application. Build the governance matrix for the baseline synthetic fixture and justify the bounded state. S3 — diagnosis. A material assessment field changes after approval but approval_revision does not. Identify the invalidated state, consequence, and minimum repair. S4 — transfer. A volunteer contributor becomes a paid editor. Recompute effective authority from current role, object scope, conflict state, and revision ownership. Do not carry old self-review privileges or approvals into the new role.

Passing requires identity/contract correctness, exact evidence binding, visible negative evidence, a decision no stronger than the evidence, and genuine recomputation in transfer. A human must be able to reproduce the result from visible evidence without hidden model reasoning.

References, freshness, and authority boundaries

FACT — W3C PROV. The PROV family defines interoperable provenance concepts around entities, activities, agents, attribution and derivation. Rechecked 2026-09-13. It is foundational/stable for this lesson. It does not define MAKNOW editorial authority.

FACT — GitHub rulesets/review controls. Current GitHub documentation still supports required approvals, code-owner review, optional approval from someone other than the most recent pusher, and dismissal of stale approvals when the reviewed diff changes. Rechecked 2026-09-13. These are evolving vendor mechanics and must be rechecked by the declared freshness date or earlier on material change.

INFERENCE — revision-scoped editorial approval. MAKNOW uses provenance plus review-control patterns to infer that an approval should be bound to the reviewed revision and become stale after material change. Exact materiality rules remain local.

DESIGN — MAKNOW capability matrix and publish gate. Role names, object scope, conflict taxonomy, recusal, review count, exception authority/expiry, publisher role, rollback policy and state vocabulary are local design authority. Accepted package bytes are never silently mutated when an external source changes.