Prerequisites and scoped previews
Labels, delayed outcomes and human annotation
Define label windows, maturity, censoring, annotation policy and disagreement.
Leakage, splits and evaluation contamination
Prevent future information, entity overlap, preprocessing leakage and test-set reuse.
Classification and rare-event evaluation
Define confusion counts, precision/recall, PR/ROC metrics, slices and threshold trade-offs.
Calibration, uncertainty and decision thresholds
Distinguish score quality from calibrated probabilities, uncertainty and action capacity.
Slices, fairness and harm-aware decisions
Define relevant slices and competing error costs without claiming one metric certifies fairness.
Registry, validation, rollout and rollback
Promote compatible artifact bundles through checks, shadow/canary and rollback gates.
Scoped prerequisite preview. The complete chapter is planned; this preview does not count as authored coverage.
Observability and operational response
Separate system, data, model, product and decision-policy signals with owners and runbooks.
Scoped prerequisite preview. The complete chapter is planned; this preview does not count as authored coverage.
Adversaries, human review and appeals
Model abuse adaptation, review capacity, policy changes and disagreement.
What, when, why and how
Policy target and product action
- what
- A policy target defines the content/context judgment under a policy revision; an action is allow, review, temporarily hold or restrict under a separate versioned decision rule.
- when
- Use this before choosing models and whenever rules, supported modalities or user permissions change.
- why
- A classifier predicts a defined label; it does not decide the entire product policy. Removing more items or maximizing aggregate accuracy can harm legitimate expression or miss consequential exposure.
- how
- Clarify unit, content revision, supported context, latency, policy categories/severity and reversible actions. Start with transparent rules plus bounded review, keep policy/model/action identities separate and assign accountable owners.
Labels, disagreement and appeals
- what
- Annotations, reports, adjudication and appeals are evidence sources with policy/context/time provenance. A mature target revision is selected under an explicit adjudication/completeness rule.
- when
- Use this for training sets, quality reports and corrections after an action is challenged.
- why
- A user report is not automatic ground truth; disagreement can reflect ambiguous guidelines or missing context. An appeal overturn may reflect a new policy rather than an error under the original one.
- how
- Record content revision, policy, annotator method, available time, provisional/adjudicated/superseded status and adjudication lineage. Freeze label revisions in datasets. Separate unresolved cases and selected appeal evidence from population error estimates.
Model, calibration and thresholds
- what
- A model can produce one or several category scores; calibration maps scores to target probabilities in a defined population. Thresholds and action rules consume them under harm/capacity constraints.
- when
- Use learned scores only after valid labels and a usable baseline exist, with distinct evidence for score quality and feasible actions.
- why
- A high score can be miscalibrated or use unavailable context. A threshold that works for one traffic mix can overload review after a policy or model release.
- how
- Compare a simple text/metadata model with optional image/text fusion, validate each modality’s availability and objective, and inspect held-out calibration/slices. Declare threshold equality and missing-signal behavior; version classifier, transforms, calibrator and action policy together.
Capacity-bounded review and overload
- what
- Review proposals, admitted cases, completed cases, backlog and pending overflow are separate states with owners and explicit windows.
- when
- Use this when uncertain cases, reports, appeals and audits compete for finite human throughput.
- why
- An unbounded queue does not create reviewers. Silently dropping overflow or treating it as benign changes policy without quality evidence.
- how
- Reserve urgent/appeal/audit capacity, bound admission and concurrent claims, track age and severity, and assign a reversible pending action with expiry/escalation. The fixture admits two of three proposed reviews and retains the third as pending-overflow.
Revision-aware actions and correction
- what
- An action targets a specific content revision under policy and decision identity. Reviewer/appeal results apply only under compatible expected context and state versions.
- when
- Use this for edits, rescoring, duplicate delivery, delayed reviewer completion and restriction restoration.
- why
- A late allow decision for an older revision can restore changed content. Last-write-wins can overwrite a more recent restriction or erase an action history.
- how
- Use conditional action/case versions and idempotency identities atomically with the authoritative change. Append corrective actions and label revisions; mark stale results superseded and requeue/re-adjudicate rather than applying them blindly.
Sampling, slices and uncertainty
- what
- Review and appeal streams are selected observations, and aggregate quality may hide language/modality/context errors.
- when
- Use population audits and slice checks to understand real action errors and coverage gaps.
- why
- A balanced test precision cannot be copied into population workload. A high completed-appeal overturn rate does not estimate every restriction’s error probability.
- how
- Define eligible population, audit inclusion design, mature adjudicated labels, per-slice counts and uncertainty. Track zero-support/unknown cohorts and missing modality paths; explain weighting assumptions and competing harms instead of declaring fairness from one score.
Compatible lifecycle and operational fallback
- what
- A moderation release binds classifier, feature/preprocess, calibrator, label target and action policy with compatible versions. Missing inputs and outages have owned action policies.
- when
- Use this for deployment, label-policy migrations, incident containment, retraining and rollback.
- why
- Process uptime is not quality; a different policy taxonomy can invalidate old thresholds and pending labels. A universal fail-open/fail-closed slogan ignores severity, reversibility and user cost.
- how
- Validate contracts/offline evidence, shadow for compatibility/load, stage controlled exposure with guardrails and keep a complete rollback. On missing required modality, do not fabricate a zero-risk score; use an explicit pending/limited path and escalation under the exercise policy.
Clarify the moderation product
We design moderation for editable text and image posts plus user reports and appeals. Video/audio decoding, identity verification, real harmful datasets and jurisdiction-specific legal rules are outside this educational implementation. We consume authoritative content/access/policy services and show their contracts.
Every score, workload, label and timing below is synthetic. The interview exercise assesses systems reasoning, not a certified safe policy. The six clarification answers establish one coherent design rather than claiming a company’s process.
| Clarifying question | Assumed answer | Consequence |
|---|---|---|
| What can be edited and what is the unit? | A text/image post revision; edits get a new immutable revision. | Bind features, labels, scores and actions to that revision. |
| What actions are reversible? | Temporary hold/limited visibility and restoration are supported. | Pending review and corrective actions have explicit state. |
| What must be synchronous? | An initial action within synthetic p99 300 ms at 500 peak items/s. | Bound preprocessing/scoring and specify asynchronous follow-up. |
| Who defines the target? | Policy team owns versioned category/context guidelines. | Model and labels declare the compatible target. |
| What review capacity exists? | 100 nominal completions/hour before reservations. | Measure arrivals, backlog and age; separate appeals/audits. |
| What quality evidence exists? | Selected reviews plus a permitted independent audit process. | Do not equate queue metrics or reports with population truth. |
Change assumptions and revise the design
If the product adds audio/video, the current image/text preprocessing and 300-ms budget no longer apply. Add modality/version contracts, bounded asynchronous processing and a policy for unprocessed content; measure quality/coverage and user impact before extending the action policy. A bigger multimodal model does not automatically satisfy the old deadline.
If review capacity falls from 100 to 40 completions/hour, update admission/reservations and escalation immediately, then reevaluate feasible thresholds and harm trade-offs using valid data. Do not pretend adding queue partitions creates human capacity or silently allow everything beyond the limit.
Hard invariants: actions name content/policy revisions; missing scores are not zero; stale results cannot change newer content automatically; retries cannot duplicate authoritative actions; every proposed case has an admitted/overflow/resolved state; corrected evidence does not rewrite immutable snapshots. These require cross-record validation beyond simple foreign keys.
Separate outcome, proxy, loss and guardrail
The desired outcome is reducing harmful exposure while avoiding mistaken restrictions, excessive delay and inaccessible correction. Count removed items is not the same as reduced harm; a rarely seen item and a widely viewed item have different impact, and exposure itself depends on prior actions.
A model may optimize per-category binary log loss; the service chooses actions using thresholds, context and capacity. Multi-label judgments allow multiple categories where policy requires them. An automatic score, a calibrated probability, a reviewer vote and a product action remain different evidence.
| Layer | Measure / denominator | Limit |
|---|---|---|
| Outcome | Policy-defined harmful exposure and legitimate-user impact in eligible cohorts | Requires independent/adequate labels and exposure context. |
| Offline score | Per-category PR/recall/calibration under mature adjudicated labels | Selected review data can bias estimates. |
| Action | False restriction/missed harm and coverage at a declared policy | Requires action-specific, population-aware evidence. |
| Operations | Review arrivals/completions/backlog/age, decision tails and fallback | Good uptime or throughput does not certify label quality. |
| Correction | Completed-appeal outcomes plus access and unresolved counts | Overturn rate is conditional on selected completed appeals. |
| Guardrails | Language/modality/service coverage and consequential error slices | No single aggregate establishes fairness. |
Deliver transparent rules and bounded review
Baseline B0 validates supported content metadata, applies versioned known rules/authoritative policy decisions and proposes uncertain supported cases for bounded human review. It records allowed/restricted/pending actions, policy identity, reason codes and review provenance. A rule match is not itself a universally trustworthy training label.
Review capacity is part of the policy. Unsupported required modality, unavailable score or source/context mismatch enters an explicit pending/limited path in this exercise with owned expiry/escalation. A product could choose another action only with an explicit harm/latency/reversibility justification.
A simple learned text/metadata candidate B1 can help prioritize or classify supported cases, compared at feasible review load and mature quality. It is preferable to keep B0 when labels, calibration, coverage or operation do not support an upgrade. Optional multimodal models remain hypotheses, not proof of better decisions.
Prioritize available signal groups
Use content signals (text/image representations under permitted access), permitted context available before decision, and operational completeness such as language/OCR availability. Prior reports may be available for a later rescore but cannot leak into an earlier upload-time model.
Reject future reviewer decisions, later appeal outcomes and post-action engagement as upload-time inputs. Changed content must invalidate revision-specific features/caches. Sensitive/inferred attributes are not required by this teaching design.
| Group / hypothesis | Representation and availability | Verification / cost |
|---|---|---|
| Text and image content | Versioned tokenizer/OCR/image transforms; exact content revision | Missing text/image/OCR and language coverage; bounded size/time. |
| Available policy context | Declared placement/context and prior permitted facts | No future reports; snapshot known-at cutoff. |
| Completeness indicators | Supported language/modality, missing/default flags | Measure fallback by cohort; no missing=benign shortcut. |
| Rejected feature | Final appeal result from next week | Target revision, never a past upload-time feature. |
Design annotation, adjudication and target maturity
An Annotation records content revision, policy version, category/label, method/reviewer, observed/available time and provisional/adjudicated/superseded status. Reports are separate evidence. When reviewers disagree, retain their judgments and send the case to declared adjudication or represent unresolved uncertainty; do not invent consensus by dropping dissent.
A label becomes eligible for a dataset only under its target’s maturity/completeness and policy rule. For this exercise, the selected target revision must be adjudicated under the compatible policy and available by the dataset cutoff; review or appeal may remain open. There is no universal fixed number of days that makes a moderation label true.
Synthetic timeline: content revision 7 is scored October 1 10:00 under P1. Two annotations become available 11:00 and 11:15 and disagree. Adjudication L1 is available 13:00. A dataset cutoff at noon cannot use L1; a 14:00 snapshot may pin it if eligibility/completeness rules hold. A later appeal revision L2 available October 3 does not mutate the October 1 snapshot.
If P2 changes the category definition, do not simply relabel old P1 outcomes as P2 truth. Define carry-forward compatibility, reannotation/adjudication and evaluation cohorts. Appeals may reflect policy change, new evidence or a prior error; keep these explanations distinct.
Audit the population and control leakage
Operational reviews depend on thresholds, reports, language, visibility and queue capacity; they are not a random sample of all content. Reserve an independently selected permitted audit with explicit inclusion rules where feasible. Unknown/no-support cases remain unknown.
The foundation’s retrospective sample has TP/FN/FP/TN 90/10/10/90 and class inclusion weights 1/99. Weighted estimates become 90/10/990/8,910, changing precision from 90% to about 8.333%. This is a distinct pedagogical sampling example, not the six-item decision fixture and not an operational sampler that magically knows all true labels.
Split by time and content/source/duplicate groups matching the deployment question; define whether creators overlap for future-known versus unseen-creator evaluation. Keep edited/near-duplicate content and repeated annotations from inflating independent evidence. Fit transforms/model/calibrator on suitable disjoint development partitions, reserve final held-out mature evaluation and record snapshot/split IDs.
Choose models, objectives and calibrated outputs
B1 can use sparse text/metadata features with a linear/logistic or tree model. Compare against B0 using the same eligible labels, population contract and action budgets. Binary log loss for a defined category uses -[y log(p)+(1-y) log(1-p)] with numerically stable implementation when actually trained.
B2 may use separate text/image encoders with late fusion or an optional joint model. Define input shape, supported modalities, missingness, category heads, label compatibility and output interpretation. Late fusion offers explicit per-modality missing/failure behavior at possible interaction-quality cost; a joint model needs additional data/resource and missing-context evaluation. Neither is universally strongest.
A multi-label target can have independent per-category outputs and an explicit category/severity/action resolver. Review category prevalence, loss weighting, incomplete labels and duplicate/creator/time leakage. Do not force mutually exclusive softmax labels when policy allows simultaneous categories; do not count unannotated categories as confirmed negatives.
Calibrate a chosen score using appropriate held-out evidence; sigmoid or isotonic mappings are alternatives with assumptions, not automatic improvements. The fixture computes reliability diagnostics for four independent synthetic points and trains neither a classifier nor a calibrator. The deployment bundle names classifier, preprocessing, calibrator and compatible action/label policies.
Work scores, thresholds and review admission
Six independently judged synthetic examples are A(score .95,label 1), B(.90,0), C(.89,1), D(.60,0), E(.40,1), F(.10,0). The labels are supplied for the hand-checkable fixture; a real operational queue does not reveal all outcomes immediately.
Policy proposal: scores < .40 allow; [.40,.90) review; >= .90 restrict. Proposed actions are restrict A/B, review C/D/E and allow F. With two review admission slots, C/D are queued by descending score then stable ID; E stays pending-overflow. All six decisions remain accounted for, and this prioritization is a declared toy rule rather than a universal severity policy.
Automatic restriction at .90 yields TP=1, FP=1, FN=2, TN=2: precision 1/2 and recall 1/3. Flagging scores >= .40 for review-or-restrict yields TP=3, FP=2, FN=0, TN=1: precision 3/5 and recall 1. The latter is a proposed flag metric, not completed review quality or a promise all harms were resolved.
A threshold .95 flags only A in this tiny set, giving precision 1 and recall 1/3. One correct flag is not adequate evidence for a safe production threshold. Tune on validation under explicit costs/capacity and assess held-out mature slices with uncertainty. Equality conventions at .40/.90/.95 must match serving and evaluation.
Inspect probabilities separately from score ranking
Independent calibration fixture: probabilities [.1,.2,.8,.9] with labels [0,1,1,1]. The low bin [0,.5) has mean .15, observed rate .5 and count 2; high bin [.5,1] has mean .85, observed rate 1 and count 2. Count-weighted absolute bin gap=.25, Brier=.175.
This is a descriptive small-data calculation. Bin choices, selected populations, labels and sampling uncertainty limit conclusions. Brier reflects discrimination and uncertainty as well as calibration. Empty bins have zero count and undefined means, and no scalar here certifies calibration, fairness or safe actions.
A monotonic recalibrator may preserve ordering but change actions at a fixed threshold. Version and validate the complete policy/calibrator release, including review arrivals and label-policy compatibility. Do not select a calibration function or thresholds on the final test and still call it untouched evaluation.
Pin data, label and artifact lineage
DatasetSnapshot records known-at cutoff, content/creator/duplicate/time split, annotation/adjudication policy and exact example references. DatasetExample links a content/score decision to a feature snapshot and one selected label revision; the label’s content/policy must match the target.
TrainingRun pins dataset, code/config/environment, objective and permitted transform versions. ModelVersion and calibrator identify their producing run and output target. A new policy taxonomy can require new labels/model/calibrator/threshold evidence; a finished run is not authorization to promote.
Publish a validated ReleaseBundle with model, preprocess, calibrator, target policy and action rules. Required gates include input/shape/version checks, metric oracles, feasible review load, coverage/slice review and clear missing-modality behavior. Distributed training, registry, annotator service and storage are proposed extensions, not implemented by the deterministic fixtures.
Trace online, offline and human paths
Online: authorized content revision → bounded preprocessing/available context → rule/model score → compatible action policy → idempotent authoritative action plus review proposal/outbox. Review workers claim bounded cases and complete conditional results; appeals reference prior actions and may create corrective actions.
Offline: permitted events/annotations/appeals → adjudicated label revisions and feature snapshots → frozen dataset/splits → candidate validation → compatible bundle gates. The paths meet through exact identities and available times, not mutable latest-row joins.
The response/action store is authoritative; caches and downstream visibility/search/recommendation projections consume versioned action events. A successful queue acknowledgement is distinct from effect application. Retry/deduplication must be atomic with the effect it protects, while projections reject older action revisions.
Preprocessing and model services use bounded queues and remaining deadlines. Missing mandatory input is an explicit missing-signal result, not a zero score. Slow human review never sits inside the synchronous scoring request; it is an owned asynchronous workflow with visible pending state.
Specify request, action, review and appeal contracts
Logical classify request: content_id, expected_content_revision, authorized context, request_id and server-enforced deadline. Response/decision: score_id or explicit unavailable reason, compatible bundle/policy, proposed/applied action, action_version, case reference and audit reason code. Client-supplied context cannot override access or policy authority.
Review completion: case_id, expected_case_version, content_revision, policy_id, result_id, decision and authorized reviewer identity. A stale version, different content/policy or conflicting result must not change current action. The reference transition demonstrates rejection; production needs the version check and effect in an authoritative transaction.
Appeal submission references an actual restriction action and content revision. Completion records adjudication context and a new correction action if appropriate; it does not erase the original. Reason messages use approved product language, avoid sensitive evidence and do not expose detailed bypass thresholds.
Events use producer identity, action/case revisions, occurred/available times and schema versions. Redeliver identical accepted facts idempotently; quarantine conflicting payloads under the same identity. An accepted telemetry event does not itself prove the user saw the changed visibility.
| Boundary | Invariant | Failure behavior |
|---|---|---|
| Content edit | Score/action targets expected immutable revision | Reject stale result; recompute or adjudicate. |
| Bundle | Policy/target/calibrator/preprocess compatible | Reject mixed version; use explicit owned fallback. |
| Review | Bounded admission, current claim/context and result identity | Keep overflow pending; reject stale/conflicting completion. |
| Appeal | References original action; authorized compatible adjudication | Append correction or escalate incompatible context. |
| Projection | Monotone applied action version per content context | Ignore/reject older effects; audit delivery lag. |
Compute reviewer capacity, backlog and inference budgets
Synthetic service assumptions: 500 peak items/s, initial p99 target 300 ms and supported bounded text/image inputs. Capacity 100 reviews/hour is a separate human window; 500 items/s means 1.8 million items/hour at sustained peak, so even a small review fraction can swamp staff. This arithmetic does not assert that peak persists for an hour.
At sustained 1.8M items/hour, .01% review proposals produce 180/hour. With 100 completions/hour and no reservations, backlog grows 80/hour absent other flows. At 120 arrivals/hour with opening backlog 30 and 100 completions, ending backlog=50. Rates and examples use different stated workloads; do not mix seconds and hours.
Twenty reviewers with 60 productive minutes/hour and 12-minute average handle time give 100 nominal cases/hour. If 20/hour is reserved for appeals/audits, the remaining ordinary-review budget is 80 under these assumptions. Expertise, breaks, difficult cases and service-time variation can change actual capacity; mean-rate stability is not a p99 waiting-time guarantee.
Authored synchronous allocation: 20 ms validation/context, 80 ms bounded preprocess, 100 ms model, 30 ms policy/action/outbox and 70 ms reserve = 300 ms. This is a budget proposal, not a measured SLO or a sum-of-p99 proof. Benchmark end-to-end correlated tails, payload-size limits and overload.
Cost worksheet separates inference requests/feature bytes and storage from reviewer/adjudication time and telemetry retention. With 120 cases/hour at 12 minutes each, required productive reviewer time is 1,440 minutes/hour=24 reviewer-hours per clock hour. Price/staffing rates are explicit inputs to fill, not live market quotes.
| Quantity | Synthetic result | Interpretation |
|---|---|---|
| Review proposal fraction at sustained peak | .0001 * 1,800,000 = 180/hour | Exceeds 100/hour by 80 before reservations. |
| One-hour backlog | 30+120-100 = 50 | Requires retained/open work; no silent drop. |
| Human staffing at 120/hour | 120*12/60 = 24 productive reviewers | More staffing/less arrivals may be needed; quality remains separate. |
| Service deadline allocation | 20+80+100+30+70 = 300 ms | Not a measured throughput or tail guarantee. |
Bound the human workflow and priority policy
A ReviewCase names content revision, target/action policy, score/action origin, case state/version, priority class, queue timestamps and authorized claim. A claim may use a lease in production, with conditional renewal/completion. The small reference implements optimistic expected-version checks only; it is not a distributed lease/queue service.
Separate urgent severity, ordinary model uncertainty, reports, appeals and independent audits. Reserve capacity explicitly and avoid counting the same reviewer at full throughput in every pool. A maximum score-first toy priority can starve old or low-score cases; production needs an owned age/severity/language policy and starvation/expiry analysis.
Every proposed item is admitted, retained pending-overflow, superseded or resolved under policy with a traceable reason. An expiry cannot simply manufacture a benign label; it triggers a declared action and escalation. Alerts include oldest-case age and priority-specific backlog, not only queue length.
Handle a stale reviewer and a compatible overturn
Normal review: R1 is queued, claimed for content revision 7, policy P1, action A1 and expected case version 3, then resolved once under an authorized compatible result. The resulting action and annotation references are durable and independently auditable.
Stale case: content is edited to revision 8 before the result arrives. A result for revision 7 is superseded/rejected and cannot allow or restrict revision 8 automatically. A policy change from P1 to P2 similarly requires an explicit compatibility/re-adjudication rule. Case version alone does not prove content/policy context is current.
Appeal AP1 challenges restriction A1 on revision 7. If the current authoritative revision/policy/action still match and an authorized adjudication overturns it, append restore action A2 with corrects_action_id=A1 and increment action version. Preserve A1, case evidence and the policy explanation; create a new label revision available at adjudication time.
A second replay must not append another correction. The fixture rejects the outdated expected action version after the first accepted transition. A production idempotency store can additionally return the accepted prior response for an identical result ID, atomically with the effect. A conflicting outcome under the same identity is a contract error.
Overturn rate among completed appeals is conditional on selected appealed cases. Separate submitted, unresolved, upheld, overturned and policy-change cases with delay/coverage counts. It does not identify the population false-restriction rate or justify treating all appeal submissions as negative labels.
Assess quality by population, action and slice
Use per-category confusion counts, precision/recall/calibration, eligibility/unknown counts and action-specific harms on adjudicated compatible-policy evidence. Report both raw audit counts and any valid inclusion weighting. Label selected-queue precision and completed-appeal outcomes as such.
Important permitted slices include language, modality/missing OCR, new/edited content, high-volume or repeated sources and fallback/review priority. A synthetic A cohort of 990 items with 980 correct and B cohort of ten with five correct yields 98.5% aggregate but 50% in B. Obtain error type, support and label consistency before choosing an intervention.
Inspect reviewer guideline consistency and adjudication disagreements, not just agreement percentage. Changes to policy, queue selector or label availability can alter observed rates without model drift. A zero-positive slice has undefined recall; keep unknown or under-supported groups visible.
Offline improvement does not establish causal harmful-exposure reduction. Shadow outputs can assess compatibility/load and compare where trustworthy labels exist. Controlled exposure requires accountable risk/guardrail design, assignment/exposure/outcome maturity and analysis discipline; do not randomly expose clearly prohibited content merely to get a label or claim a universal experiment duration.
Promote compatible bundles and correct bad releases
Gate a candidate on source/data contracts, independent math/state fixtures, compatible policy/label targets, held-out/slice evidence, feasible review workload and missing-input behavior. Shadow for action/load differences, then stage appropriate controlled release under accountable guardrails; human/policy review is not replaced by a scalar score.
Rollback restores the complete classifier/preprocess/calibrator/action-policy bundle where compatible with current policy. If policy P1 is no longer permissible, an old P1 bundle cannot simply be restored; enter an approved fallback and rebuild/re-adjudicate under current policy. Keep this distinction explicit.
A bad release that sends 180 proposals/hour into a 100/hour service needs immediate load/action containment and owned pending state. Later quality evidence may be delayed. Retraining is not the first repair for a mismatched policy, broken OCR or incorrect queue admission.
Corrected labels or policy revisions create new dataset/run evidence and promotion gates. Preserve what was known when; do not silently edit old benchmark rows or erase wrong actions to improve reported metrics.
Trace normal, boundary and failure scenarios
Normal: content C1 revision 7 under P1 is scored by a compatible bundle, an action is durably recorded, a review is admitted if required, and a matching authorized result advances the case/action once. Later audit/adjudication yields versioned labels.
Boundary: a required image/OCR result is unavailable or a score is NaN. Do not convert it to zero; route through explicit pending-missing-signal handling under the exercise policy. This consumes user-impact/age budget and needs expiry/escalation. A score exactly on a threshold follows the declared equality convention.
Failure: review capacity admits only two of three proposed cases. Retain the third with pending-overflow state and an owner; record backlog and oldest age. If the same item is retried, deduplicate identity rather than creating duplicate work.
Failure: edited content, changed policy or a newer action arrives before review/appeal completion. Reject the stale context before authoritative effect, retain superseded evidence and create new work or adjudicate explicitly. An older projection event cannot overwrite a newer action version.
Recovery: restore a permitted compatible bundle or approved fallback, drain/reprioritize work without losing case identities, verify current action/projection samples, and compare immediate system/load signals with later mature quality/appeal evidence. The reference exercises the boundary arithmetic and state contracts, not distributed infrastructure.
Connect alerts to owners and observable evidence
System signals: decision tails/errors, preprocess/model saturation, action outbox/projection lag and duplicate/conflicting events. Data/model signals: unsupported inputs, missing modality/defaults, policy/label revision mix, confidence/calibration and compatible mature slices. Human signals: arrivals/admissions/completions/overflow/age by priority and adjudication delay.
Product/policy signals: sampled harmful exposure, mistaken restriction evidence, accessibility/appeal coverage and legitimate-user delay. Some require delayed or selected labels; distribution change alone cannot prove quality loss. Track who can interpret each signal and what immediate containment is authorized.
| Signal | Owner / first action | Limit |
|---|---|---|
| Policy/bundle mismatch | Release/policy owner: reject mixed decision, choose permitted fallback | A previous bundle may be incompatible with current policy. |
| Review age/overflow surge | Review ops/product: cap work, enact owned pending/priority plan | Queue scale alone cannot increase human completions. |
| Missing OCR/language coverage | Preprocess/data owner: repair service or explicit fallback | Exclude-only-complete evaluation would hide the gap. |
| Appeal/stale-result conflict | Action/review owner: reject stale mutation and audit lineage | Submission alone is not proof of prior model error. |
| Mature slice regression | Domain/model/data owners: validate labels/sampling, contain harm | No aggregate metric certifies fairness or causality. |
Own access, retention, reviewer care and policy changes
Reviewer access is least-privilege and purpose-bound, with redacted routine traces and audited evidence access. Store only permitted content/evidence under explicit retention/deletion processes. The curriculum uses opaque synthetic records and requires no actual harmful content or personal reviewer/user data.
Deletion/retention can affect content blobs, features, annotation evidence, datasets and derived artifacts; removing a current row does not prove all trained influence disappeared. Describe supported rebuild/retraining and audit-minimum boundaries without promising universal model unlearning.
Policy owns taxonomy and action authority; model/data teams own label/score contracts and evidence; review ops owns staffing/quality/age; platform/SRE owns state, budgets and recovery; product owns user-impact trade-offs and appeal access. State cross-team escalation, change approval and independent review explicitly.
Staff exercises: migrate P1 to P2 while open cases/appeals and regional bundles exist; contain a surge without erasing overflow; repair a selected-label benchmark while explaining a metric drop; reconcile legitimate-user friction against harmful-exposure goals. Each requires measurable evidence, ownership and a reversible migration where possible.
Data model, schema and relationships
Proposed logical schema for editable content, policy decisions, bounded review and corrections. IDs are global in this synthetic product; a multi-tenant adaptation requires tenant-qualified authorization/keys. A FK proves identity, not revision compatibility, permission, timing or capacity.
Implementation boundary: Logical educational contracts and pure synthetic fixtures. No migration, real content store, reviewer platform, trained model or production moderation action is deployed.
These are proposed logical schemas with field contracts, not executable database migrations. PK identifies a row, FK references an existing parent, UK is a uniqueness rule. A composite PK identifies the combination. Nullable references are marked with ?. A foreign key protects identity; cross-row limits, timing and state transitions also require the transaction rules below.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Connectors name the relationship; multiplicities state parents per child and children per parent. 0..1 means optional, 1 required, 0..* any number. Self-links show two roles of the same entity.
Entity definitions and field contracts
Content
Stable identity with authoritative current revision/action references.
| Field | Type / key | Meaning and reference |
|---|---|---|
content_id | opaque ID · PK | Global item identity; owner/access authority is external. |
current_revision_id | string? · FK | Current immutable content revision. · content_revision.revision_id |
current_action_id | string? · FK | Current authoritative action pointer. · action.action_id |
deleted_at | timestamp? · VALUE | Retention/revocation marker and permitted minimum evidence. |
Code mapping: Authorized content service and edit/current-action context.
- Pointer changes and expected-version checks require an authoritative transaction.
ContentRevision
Immutable edited content and supported modality metadata.
| Field | Type / key | Meaning and reference |
|---|---|---|
revision_id | string · PK | Opaque revision identity, such as C1-r7. |
content_id | opaque ID · FK | Owning item. · content.content_id |
revision_number | integer · VALUE | Ordered revision within content; unique with content ID. |
blob_reference | restricted artifact · VALUE | Permitted payload reference; no raw content in routine traces. |
modality_available_at | struct · VALUE | Text/image/language/OCR completeness and availability. |
Code mapping: Exact scoring/annotation/action target.
- Unique(content_id, revision_number); edits create new rows.
PolicyVersion
Target taxonomy, action authority and compatibility rules.
| Field | Type / key | Meaning and reference |
|---|---|---|
policy_id | string · PK | Immutable policy/guideline identity. |
target_action_contract | artifact ref · VALUE | Categories, context, thresholds/resolver and missing/overflow rules. |
effective_window | timestamps · VALUE | When this policy may be used. |
compatibility_rules | artifact ref · VALUE | Explicit carry-forward/re-adjudication rules; not assumed from version names. |
Code mapping: Fixture P1 contract and design-only policy governance.
- A retired/incompatible policy is not an automatic rollback target.
Report
Selected user/system evidence; not an automatic truth label.
| Field | Type / key | Meaning and reference |
|---|---|---|
report_id | string · PK | Stable producer report identity. |
revision_id | string · FK | Reported content revision. · content_revision.revision_id |
source_context | redacted struct · VALUE | Permitted reporter/provenance and reason context. |
event_available_at | timestamps · VALUE | Observed and validated availability times. |
Code mapping: Reports feed and sampling-selection evidence.
- Deduplicate stable identity; validate permitted access and suspicious conflicts.
Annotation
Reviewer/model-independent or adjudicated policy judgment.
| Field | Type / key | Meaning and reference |
|---|---|---|
annotation_id | string · PK | Immutable annotation/evidence identity. |
revision_id | string · FK | Exact content revision judged. · content_revision.revision_id |
policy_id | string · FK | Guideline/target used. · policy_version.policy_id |
review_result_id | string? · FK | Originating authorized review result when present. · review_result.result_id |
label_method_status | struct · VALUE | Category values, reviewer method, disagreement and provisional/adjudicated state. |
observed_available_at | timestamps · VALUE | When observed and when usable downstream. |
Code mapping: Annotation/adjudication and policy-label lineage.
- Multiple annotations may disagree; do not collapse into consensus by deleting evidence.
LabelRevision
Dataset-eligible adjudicated target under an explicit policy.
| Field | Type / key | Meaning and reference |
|---|---|---|
label_id | string · PK | Immutable target revision identity. |
annotation_id | string · FK | Anchor adjudication; evidence manifest retains other judgments. · annotation.annotation_id |
revision_id | string · FK | Exact content target. · content_revision.revision_id |
policy_id | string · FK | Compatible label definition. · policy_version.policy_id |
value_status_completeness | struct · VALUE | Positive/negative/unknown, adjudication and source-completeness proof. |
available_at | timestamp · VALUE | Known-at cutoff eligibility; later corrections create new rows. |
Code mapping: As-of label selection fixture and immutable revisions.
- Label content/policy must match its anchor annotation and dataset target.
FeatureSnapshot
Permitted available input/transform lineage for scoring.
| Field | Type / key | Meaning and reference |
|---|---|---|
feature_id | string · PK | Immutable feature revision manifest. |
revision_id | string · FK | Exact content revision. · content_revision.revision_id |
known_at | timestamp · VALUE | Input availability cutoff at decision. |
transform_missingness | struct · VALUE | Tokenizer/OCR/preprocess versions, defaults and missing flags. |
Code mapping: Feature availability and missing-signal boundaries.
- Future review/appeal outcomes cannot enter upload-time inputs.
DatasetSnapshot
Frozen evaluation/training population and split contract.
| Field | Type / key | Meaning and reference |
|---|---|---|
dataset_id | string · PK | Immutable snapshot identity. |
policy_id | string · FK | Target policy. · policy_version.policy_id |
known_at_cutoff | timestamp · VALUE | Label availability boundary; per-decision features have earlier cutoffs. |
split_sampling_manifest | artifact ref · VALUE | Time/source/creator/duplicate partitions, inclusion probabilities and unknown counts. |
Code mapping: Frozen data/label/sampling contract.
- Corrections or target changes create a new snapshot.
DatasetExample
Explicit feature/label/content membership of one snapshot.
| Field | Type / key | Meaning and reference |
|---|---|---|
example_id | string · PK | Immutable example identity. |
dataset_id | string · FK | Owning frozen snapshot. · dataset_snapshot.dataset_id |
revision_id | string · FK | Exact content revision. · content_revision.revision_id |
feature_id | string · FK | Exact available input record. · feature_snapshot.feature_id |
label_id | string · FK | One eligible target revision. · label_revision.label_id |
split_weight | struct · VALUE | Train/validation/test and justified sample weighting. |
Code mapping: Leakage, sampling and evaluation lineage.
- Feature/label/content/policy references must agree; FK identity alone is insufficient.
- Unique snapshot/target revision under declared example construction.
TrainingRun
Design-only candidate fit and validation provenance.
| Field | Type / key | Meaning and reference |
|---|---|---|
run_id | string · PK | Run identity and retry/publication namespace. |
dataset_id | string · FK | Producing frozen dataset. · dataset_snapshot.dataset_id |
code_config_environment | artifact refs · VALUE | Objective/seed/environment and declared calibrator fitting boundaries. |
validation_state_report | struct · VALUE | Shape, quality, capacity and slice evidence; completion does not promote. |
Code mapping: Design-only training/calibration pipeline.
- Model/calibrator fit and final assessment roles remain disjoint as declared.
ModelVersion
Classifier or calibrator artifact and target identity.
| Field | Type / key | Meaning and reference |
|---|---|---|
model_id | string · PK | Immutable artifact version. |
run_id | string · FK | Producing candidate run. · training_run.run_id |
policy_id | string · FK | Output target/taxonomy compatibility. · policy_version.policy_id |
role_shape_hash | struct · VALUE | Classifier/calibrator role, category outputs, transforms and integrity hash. |
Code mapping: Bundle compatibility contract.
- A calibrator role is not interchangeable with a classifier; both target compatibility and shape are validated.
ReleaseBundle
Complete current-policy compatible serving reference.
| Field | Type / key | Meaning and reference |
|---|---|---|
bundle_id | string · PK | Immutable release identity. |
classifier_id | string · FK | Classifier artifact. · model_version.model_id |
calibrator_id | string? · FK | Optional calibrator; absence is explicit. · model_version.model_id |
policy_id | string · FK | Permitted target/action policy. · policy_version.policy_id |
preprocess_action_versions | struct · VALUE | Transforms, score interpretation, thresholds, overflow/missing policies and gates. |
Code mapping: Current-policy release and rollback/fallback decision.
- Policy/role/output/preprocess compatibility precedes promotion.
ScoreDecision
Score or explicit unavailable state under exact context.
| Field | Type / key | Meaning and reference |
|---|---|---|
score_id | string · PK | Stable scoring request/result identity. |
revision_id | string · FK | Content evaluated. · content_revision.revision_id |
policy_id | string · FK | Target/action context. · policy_version.policy_id |
feature_id | string? · FK | Permitted input snapshot where recorded. · feature_snapshot.feature_id |
bundle_id | string? · FK | Null on explicit rule/unavailable path. · release_bundle.bundle_id |
scores_reason_time | struct · VALUE | Finite category scores or unavailable reason, rule identity and decision time. |
Code mapping: Six-item score/action fixture; no trained classifier.
- Missing/NaN is not a zero-risk score.
- Input, bundle, content and policy contexts must agree.
Action
Append-only visibility/pending decision and correction history.
| Field | Type / key | Meaning and reference |
|---|---|---|
action_id | string · PK | Authoritative action identity. |
revision_id | string · FK | Exact revision affected. · content_revision.revision_id |
policy_id | string · FK | Authority for the action. · policy_version.policy_id |
score_id | string? · FK | Originating score or explicit rule/manual path. · score_decision.score_id |
source_result_id | string? · FK | Authorized reviewer result when present. · review_result.result_id |
corrects_action_id | string? · FK | Prior action corrected without deletion. · action.action_id |
kind_version_reason | struct · VALUE | Allow/restrict/pending/restore, monotone action version and approved reason. |
Code mapping: Conditional correction and stale-result fixture.
- Unique content/action version with expected current-pointer checks.
- Restoration must match current content/policy/action context and authority.
ReviewCase
Durable bounded work, claim state and expected context.
| Field | Type / key | Meaning and reference |
|---|---|---|
case_id | string · PK | Stable case identity prevents repeated proposal work. |
revision_id | string · FK | Expected content revision. · content_revision.revision_id |
policy_id | string · FK | Expected guideline/target context. · policy_version.policy_id |
action_id | string? · FK | Action awaiting adjudication. · action.action_id |
report_id | string? · FK | Optional report origin. · report.report_id |
appeal_id | string? · FK | Optional appeal-specific review work. · appeal.appeal_id |
state_version_priority | struct · VALUE | Pending/queued/claimed/resolved/superseded, version, age, priority and claim metadata. |
Code mapping: Admission and optimistic review transition fixture.
- Source identity, expected versions and bounded admission are authoritative invariants.
- An expired or overflow case does not become a negative label.
- At least one action/report/appeal source is present, and its content/policy context must agree. Independent audit cases reference the existing action plus the declared sampling manifest.
ReviewResult
Immutable authorized reviewer outcome, including superseded evidence.
| Field | Type / key | Meaning and reference |
|---|---|---|
result_id | string · PK | Stable completion identity; conflicting payload rejected. |
case_id | string · FK | Reviewed case. · review_case.case_id |
revision_id | string · FK | Observed content revision. · content_revision.revision_id |
policy_id | string · FK | Guidelines used. · policy_version.policy_id |
expected_versions_outcome | struct · VALUE | Case/action versions, authorized identity and allow/restrict/escalate outcome. |
available_at | timestamp · VALUE | Availability for action/label checks. |
Code mapping: Conditional completion and annotation origin.
- Accepted effect requires current content/policy/case/action context; retain stale evidence without applying it.
Appeal
Selected challenge to an action; not automatic proof of error.
| Field | Type / key | Meaning and reference |
|---|---|---|
appeal_id | string · PK | Idempotent submission identity. |
original_action_id | string · FK | Restriction challenged. · action.action_id |
revision_id | string · FK | Original target context. · content_revision.revision_id |
policy_id | string · FK | Declared adjudication context. · policy_version.policy_id |
status_reason_times | struct · VALUE | Submitted/pending/upheld/overturned/policy-change and event/available times. |
Code mapping: Appeal denominator and correction lineage.
- Compatible authorized adjudication appends a correction; changed context requires explicit handling.
ActionEvent
Transactional publication of an authoritative action to projections.
| Field | Type / key | Meaning and reference |
|---|---|---|
event_id | string · PK | Stable outbox/event identity. |
action_id | string · FK | Published action. · action.action_id |
aggregate_version | integer · VALUE | Monotone per-content action version. |
delivery_state | struct · VALUE | Accepted/retry/published metadata; delivery is not effect acknowledgement. |
Code mapping: Design-only outbox; deterministic monotone-projection fixture.
- Action and outbox identity commit together; consumers reject stale/conflicting aggregate versions.
Relationship cardinalities and their reasons
| Parent → child | Multiplicity | FK / why |
|---|---|---|
| content_revision → content current revision id | 0..1 parent per child; 0..* children per parent | content.current_revision_id → content_revision.revision_idEach child references zero or one content_revision; a parent may have many children. Current immutable content revision. |
| action → content current action id | 0..1 parent per child; 0..* children per parent | content.current_action_id → action.action_idEach child references zero or one action; a parent may have many children. Current authoritative action pointer. |
| content → content_revision content id | 1 parent per child; 0..* children per parent | content_revision.content_id → content.content_idEach child references exactly one content; a parent may have many children. Owning item. |
| content_revision → report revision id | 1 parent per child; 0..* children per parent | report.revision_id → content_revision.revision_idEach child references exactly one content_revision; a parent may have many children. Reported content revision. |
| content_revision → annotation revision id | 1 parent per child; 0..* children per parent | annotation.revision_id → content_revision.revision_idEach child references exactly one content_revision; a parent may have many children. Exact content revision judged. |
| policy_version → annotation policy id | 1 parent per child; 0..* children per parent | annotation.policy_id → policy_version.policy_idEach child references exactly one policy_version; a parent may have many children. Guideline/target used. |
| review_result → annotation review result id | 0..1 parent per child; 0..* children per parent | annotation.review_result_id → review_result.result_idEach child references zero or one review_result; a parent may have many children. Originating authorized review result when present. |
| annotation → label_revision annotation id | 1 parent per child; 0..* children per parent | label_revision.annotation_id → annotation.annotation_idEach child references exactly one annotation; a parent may have many children. Anchor adjudication; evidence manifest retains other judgments. |
| content_revision → label_revision revision id | 1 parent per child; 0..* children per parent | label_revision.revision_id → content_revision.revision_idEach child references exactly one content_revision; a parent may have many children. Exact content target. |
| policy_version → label_revision policy id | 1 parent per child; 0..* children per parent | label_revision.policy_id → policy_version.policy_idEach child references exactly one policy_version; a parent may have many children. Compatible label definition. |
| content_revision → feature_snapshot revision id | 1 parent per child; 0..* children per parent | feature_snapshot.revision_id → content_revision.revision_idEach child references exactly one content_revision; a parent may have many children. Exact content revision. |
| policy_version → dataset_snapshot policy id | 1 parent per child; 0..* children per parent | dataset_snapshot.policy_id → policy_version.policy_idEach child references exactly one policy_version; a parent may have many children. Target policy. |
| dataset_snapshot → dataset_example dataset id | 1 parent per child; 0..* children per parent | dataset_example.dataset_id → dataset_snapshot.dataset_idEach child references exactly one dataset_snapshot; a parent may have many children. Owning frozen snapshot. |
| content_revision → dataset_example revision id | 1 parent per child; 0..* children per parent | dataset_example.revision_id → content_revision.revision_idEach child references exactly one content_revision; a parent may have many children. Exact content revision. |
| feature_snapshot → dataset_example feature id | 1 parent per child; 0..* children per parent | dataset_example.feature_id → feature_snapshot.feature_idEach child references exactly one feature_snapshot; a parent may have many children. Exact available input record. |
| label_revision → dataset_example label id | 1 parent per child; 0..* children per parent | dataset_example.label_id → label_revision.label_idEach child references exactly one label_revision; a parent may have many children. One eligible target revision. |
| dataset_snapshot → training_run dataset id | 1 parent per child; 0..* children per parent | training_run.dataset_id → dataset_snapshot.dataset_idEach child references exactly one dataset_snapshot; a parent may have many children. Producing frozen dataset. |
| training_run → model_version run id | 1 parent per child; 0..* children per parent | model_version.run_id → training_run.run_idEach child references exactly one training_run; a parent may have many children. Producing candidate run. |
| policy_version → model_version policy id | 1 parent per child; 0..* children per parent | model_version.policy_id → policy_version.policy_idEach child references exactly one policy_version; a parent may have many children. Output target/taxonomy compatibility. |
| model_version → release_bundle classifier id | 1 parent per child; 0..* children per parent | release_bundle.classifier_id → model_version.model_idEach child references exactly one model_version; a parent may have many children. Classifier artifact. |
| model_version → release_bundle calibrator id | 0..1 parent per child; 0..* children per parent | release_bundle.calibrator_id → model_version.model_idEach child references zero or one model_version; a parent may have many children. Optional calibrator; absence is explicit. |
| policy_version → release_bundle policy id | 1 parent per child; 0..* children per parent | release_bundle.policy_id → policy_version.policy_idEach child references exactly one policy_version; a parent may have many children. Permitted target/action policy. |
| content_revision → score_decision revision id | 1 parent per child; 0..* children per parent | score_decision.revision_id → content_revision.revision_idEach child references exactly one content_revision; a parent may have many children. Content evaluated. |
| policy_version → score_decision policy id | 1 parent per child; 0..* children per parent | score_decision.policy_id → policy_version.policy_idEach child references exactly one policy_version; a parent may have many children. Target/action context. |
| feature_snapshot → score_decision feature id | 0..1 parent per child; 0..* children per parent | score_decision.feature_id → feature_snapshot.feature_idEach child references zero or one feature_snapshot; a parent may have many children. Permitted input snapshot where recorded. |
| release_bundle → score_decision bundle id | 0..1 parent per child; 0..* children per parent | score_decision.bundle_id → release_bundle.bundle_idEach child references zero or one release_bundle; a parent may have many children. Null on explicit rule/unavailable path. |
| content_revision → action revision id | 1 parent per child; 0..* children per parent | action.revision_id → content_revision.revision_idEach child references exactly one content_revision; a parent may have many children. Exact revision affected. |
| policy_version → action policy id | 1 parent per child; 0..* children per parent | action.policy_id → policy_version.policy_idEach child references exactly one policy_version; a parent may have many children. Authority for the action. |
| score_decision → action score id | 0..1 parent per child; 0..* children per parent | action.score_id → score_decision.score_idEach child references zero or one score_decision; a parent may have many children. Originating score or explicit rule/manual path. |
| review_result → action source result id | 0..1 parent per child; 0..* children per parent | action.source_result_id → review_result.result_idEach child references zero or one review_result; a parent may have many children. Authorized reviewer result when present. |
| action → action corrects action id | 0..1 parent per child; 0..* children per parent | action.corrects_action_id → action.action_idEach child references zero or one action; a parent may have many children. Prior action corrected without deletion. |
| content_revision → review_case revision id | 1 parent per child; 0..* children per parent | review_case.revision_id → content_revision.revision_idEach child references exactly one content_revision; a parent may have many children. Expected content revision. |
| policy_version → review_case policy id | 1 parent per child; 0..* children per parent | review_case.policy_id → policy_version.policy_idEach child references exactly one policy_version; a parent may have many children. Expected guideline/target context. |
| action → review_case action id | 0..1 parent per child; 0..* children per parent | review_case.action_id → action.action_idEach child references zero or one action; a parent may have many children. Action awaiting adjudication. |
| report → review_case report id | 0..1 parent per child; 0..* children per parent | review_case.report_id → report.report_idEach child references zero or one report; a parent may have many children. Optional report origin. |
| appeal → review_case appeal id | 0..1 parent per child; 0..* children per parent | review_case.appeal_id → appeal.appeal_idEach child references zero or one appeal; a parent may have many children. Optional appeal-specific review work. |
| review_case → review_result case id | 1 parent per child; 0..* children per parent | review_result.case_id → review_case.case_idEach child references exactly one review_case; a parent may have many children. Reviewed case. |
| content_revision → review_result revision id | 1 parent per child; 0..* children per parent | review_result.revision_id → content_revision.revision_idEach child references exactly one content_revision; a parent may have many children. Observed content revision. |
| policy_version → review_result policy id | 1 parent per child; 0..* children per parent | review_result.policy_id → policy_version.policy_idEach child references exactly one policy_version; a parent may have many children. Guidelines used. |
| action → appeal original action id | 1 parent per child; 0..* children per parent | appeal.original_action_id → action.action_idEach child references exactly one action; a parent may have many children. Restriction challenged. |
| content_revision → appeal revision id | 1 parent per child; 0..* children per parent | appeal.revision_id → content_revision.revision_idEach child references exactly one content_revision; a parent may have many children. Original target context. |
| policy_version → appeal policy id | 1 parent per child; 0..* children per parent | appeal.policy_id → policy_version.policy_idEach child references exactly one policy_version; a parent may have many children. Declared adjudication context. |
| action → action_event action id | 1 parent per child; 0..* children per parent | action_event.action_id → action.action_idEach child references exactly one action; a parent may have many children. Published action. |
Transaction boundaries
- Change authoritative action/current pointers and append an action/outbox event under an expected content/action version in one transaction.
- Admit or retain each proposed case with stable identity and an explicit state; claim/complete using current context and conditional case version.
- Accept a reviewer/appeal effect only when current content/policy/action and authorized result match; append correction history instead of overwriting prior actions.
- Publish immutable dataset/model/bundle references only after declared compatibility and evidence gates; reject partial or mixed-policy artifacts.
Indexes and uniqueness
- Unique(content_id, revision_number) and per-content action version preserve edit/action order.
- Unique producer result/event/case identities protect retries; conflicting payloads require quarantine.
- Review queue indexes use priority/state/created time and claim expiry under a declared starvation policy.
- Label lookup indexes policy/content revision, adjudicated status and available_at for known-at selection.
- Dataset example indexes snapshot, split, content revision and label reference for lineage/deletion/rebuild operations.
Schema traps and failure cases
- A valid FK cannot authorize a revision-7 result to change revision 8 or a P1 target to act under incompatible P2.
- Pending overflow/missing signals are explicit actions/work states, not negative ground truth.
- A completed appeal is selected evidence; its denominator does not cover all restrictions.
- A valid old outbox event must not overwrite a newer projection; stable identity and aggregate version protect different failure modes.
- Deleting a current content row does not automatically remove every derived snapshot or trained influence; follow the supported retention/rebuild process.
Trace the records through one operation
- Score C1-r7 under P1 using exact available features and a compatible bundle or explicit rule path.
- Create authoritative action A1 and its outbox event; propose case R1 with bounded admission or retained pending state.
- Claim R1 under version/context checks; retain and reject a result that targets an edit or incompatible policy.
- A compatible result may produce an annotation/adjudicated label L1 at its true available time.
- DatasetExample X1 pins content/features/L1 and a split/weight inside snapshot S1; later L2 corrections create new evidence.
- An authorized compatible appeal to A1 appends restore A2; a repeated or stale completion cannot append another effect.
- Consumers apply monotone action versions while preserving the content-revision target and auditing stale delivery.
Execute the moderation and review trace
Deterministic calculations over opaque synthetic records. No classifier training, real content, distributed queue or production action is executed.
Moderation step 1 of 4
Propose actions and account for review capacity
A: restrict; B: restrict; C: queued; D: queued; E: pending-overflow; F: allow. Proposed reviews=3; admitted=2; pending overflow=1. These are synthetic policy choices, not validated safe thresholds.
Diagrams and relationships
A noon snapshot cannot use the 13:00 adjudication or later appeal revision.
Scroll horizontally on smaller screens, or enlarge the diagram.
Full field/cardinality maps follow. Restriction history is retained when a correction is accepted.
Scroll horizontally on smaller screens, or enlarge the diagram.
This is a design path. The executable fixture performs only synthetic arithmetic and state checks.
Scroll horizontally on smaller screens, or enlarge the diagram.
Proposal, admission, action and completion are separate records with distinct acknowledgements.
Scroll horizontally on smaller screens, or enlarge the diagram.
A revision/policy/version mismatch supersedes the old result; current content gets explicit new work.
Scroll horizontally on smaller screens, or enlarge the diagram.
Engineer, Senior and Staff follow-ups
These are teaching lenses. Each answer changes the scope of reasoning; they are not official employer leveling criteria.
Engineer: What are the six-item outcomes with two review slots?
A/B propose restrict, C/D/E propose review and F allow. Admit C/D; E stays pending-overflow. Restriction precision is 1/2 and recall 1/3 using the independently supplied labels. Proposed review is not completed adjudication.
Engineer: Which label can a noon snapshot use?
It cannot use the adjudication available at 13:00 or the later appeal revision. Earlier disagreements remain provisional/unknown unless another explicit compatible rule adjudicates them. Pin the selected revision and known-at cutoff.
Senior: How do you prevent a late appeal from restoring edited content?
Require current content revision, policy, referenced action and expected action/case version before the authoritative effect. Reject/supersede mismatches and route to explicit adjudication; append accepted corrections instead of overwriting history.
Senior: What do you do when review arrivals exceed capacity?
Bound admission and claims, retain owned overflow/pending state, measure age by severity and reserve capacity explicitly. Reevaluate feasible policy under harm/user-delay constraints; queue scaling or silently allowing overflow is not a justified capacity plan.
Staff: How do you roll back when P1 is no longer allowed?
A technical rollback to old weights may violate current policy. Use an approved current-policy fallback, preserve evidence, re-adjudicate incompatible open work and build a compatible release. Coordinate policy/model/review/operations owners with staged regional verification.
Staff: How do you interpret a worsening appeal overturn rate?
Separate changes in who appeals, completion delay, policy definitions, evidence and actual error. Use selected-denominator labels and independent audits with uncertainty. Do not attribute causality to the model or redefine all appealed items as benign without compatible adjudication.
Practice and self-review
Your practice draft
Design editable text/image moderation with versioned policy, 300-ms synthetic initial action budget, finite human review and appeals. Explain baseline, labels/splits, score/calibration/action policy, full schema/lineage, capacity, stale-result rejection, rollback and observable recovery. Change the input to unsupported modality and cut review staffing.
Saved locally on this device. The worked answer does not score your draft. Existing lesson notes and completion are separate.
Progressive hints
Hint 1
Define the content revision, policy target and reversible action before selecting a model.
Hint 2
Account for every proposal and keep pending/unknown separate from allowed/negative; compute per-hour load.
Hint 3
Require current revision/policy/action/case versions for reviewer/appeal effects, and validate the whole release rather than weights alone.
Reveal worked answer guidance
A coherent answer starts with rules and bounded review, defines adjudicated policy-versioned labels with availability and selected-population limits, and separates raw scores, calibration and action thresholds. The six-item fixture restricts A/B, admits C/D, retains E as pending-overflow and allows F. It computes threshold/confusion and calibration diagnostics without claiming safety. It pins content/feature/label/run lineage, bounds preprocessing/inference/claims, rejects stale edits/policy/versions, and appends compatible corrections. It estimates human arrivals/backlog separately from machine capacity, stages current-policy bundles with rollback or approved fallback, and assigns audit/slice/privacy/review ownership.
Evidence to check in your answer
- Clear decision, reversible actions, six answered clarifications and changed-assumption branches.
- Label/policy/availability, annotation disagreement, sampling, splits and appeal selection are explicit.
- Complete baseline, modeling alternatives, calibration diagnostics and capacity-feasible action policy.
- Concrete PK/FK/cardinality, feature/label/run/action lineage and cross-record state invariants.
- Normal, boundary, overflow, stale-review and appeal-correction traces preserve state and identity.
- Gated current-policy release/recovery, owner-action signals, cost units and human/technical review limits.
For each item, record Missing, Prompted, Independent or Adaptive evidence. Adaptive means you can revise the reasoning under a changed constraint. Reading completion and readiness are separate.
Sources and verification scope
Original synthetic examples and reference calculations. Sources support narrowly scoped background; they do not establish production performance or independent chapter review.
Rules of Machine Learning ↗ · Baseline/infrastructure and training-serving consistency principles; dated examples are not current architecture claims.
NIST AI Risk Management Framework ↗ · Risk vocabulary and governance; not a certification or blanket legal-compliance guarantee.
Metrics and scoring ↗ · Metric definitions and implementation conventions; pin versions and specify formula/edge policies.
scikit-learn probability calibration ↗ · Reliability/held-out calibration context; original bin and Brier arithmetic. Brier is not a calibration-only measure; no calibrator is trained.
Google ML evaluating for bias ↗ · General population/slice-evaluation context, not a fairness certificate or a specific moderation policy.
Google ML thresholds and confusion matrices ↗ · Score/threshold/count context. All action thresholds, sample populations and review budgets are synthetic teaching assumptions.
Primary background links checked during authoring on 2026-10-19. Arithmetic, temporal eligibility, maturity and split reference functions are checked by the bounded local fixture suite. SQL is explanatory, not a migrated production query. No GPU, external dataset, model API or training job is required.