In most data annotation platforms, quality control is a software feature. A flag in the code. A rule that can be toggled off, bypassed by an admin, or broken by a bug.
At OraData, quality control is a database constraint. It cannot be turned off. Not by us, not by an admin, not by anyone. Here is how.
The Golden Rule states: a contributor never annotates, validates, or certifies data they collected themselves. This applies to everyone — from Bronze-tier collectors to Diamond-tier PhD experts. No exceptions.
We enforce this rule at three independent levels:
Layer 1: CHECK constraints. Every annotation row has a CHECK that compares the annotator ID with the uploader ID snapshot. If they match, the INSERT fails. This is a PostgreSQL-level constraint — it cannot be bypassed by application code.
Layer 2: BEFORE INSERT triggers. Even if someone tries to manipulate the uploader_id_snapshot field, a trigger fires before every INSERT and forces the snapshot to match the actual uploader from the raw_data table. You cannot fake the snapshot.
Layer 3: Row Level Security (RLS) policies. The INSERT policy on the annotations table refuses any row where the annotator matches the uploader. Even if layers 1 and 2 were somehow bypassed (they cannot be), RLS would catch it.
The result: three independent systems, any one of which is sufficient to enforce the rule. All three must fail simultaneously for a violation to occur — which is architecturally impossible in PostgreSQL.
This is not a feature we built. It is a constraint we imposed on ourselves. And it is what makes OraData data trustworthy.