All posts
Technology

The Golden Rule: why no one validates their own data

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.