Community Checking

ODD has orient, challenge, gate, encode, preflight, and validate. But validate currently checks "did you produce the required artifacts." It does not check "did the outcome survive contact with other humans."

These are fundamentally different questions. An output can perfectly match the team's intent and completely fail to transfer. A document can satisfy every checklist item and confuse every reader. A feature can pass every test and frustrate every user.

Community checking is the missing validation layer. It tests transfer, not correctness. It asks the target community — not experts, not the authoring team, not the AI — whether the output actually works for them. Their response is not feedback. It is evidence. It enters the ledger as an observation that either confirms the output or surfaces a constraint.

In Church Based Bible Translation and nearly all expressions of Oral Bible Translation, a translation team produces a rendering in the target language. Then they sit with people from the target community and observe: Do they understand it? Does it produce the right response? Can they retell it accurately? The checking is not "is this technically correct" — it is "did this transfer?"

This practice has been refined over decades across hundreds of languages. Its core insight is simple: the translation team cannot be the audience. Fluency in the source material does not guarantee comprehension in the target community. The only way to know if something transferred is to test it with the people it's for.

Software — Users test the feature. Not QA, not the product owner — the actual users. Do they understand it? Can they complete the task? Does it match their mental model?

Writing/Documentation — Readers consume the document. Not editors, not reviewers — the target readers. Do they understand the argument? Can they act on it? Do they arrive at the right conclusions?

Film/Video — Audience watches the output. Not the director, not the editor — the intended audience. Does it produce the intended response? Do they understand the narrative?

Education — Learners engage with the curriculum. Not the instructor, not curriculum designers — the students. Did the knowledge transfer? Can they apply it? Can they teach it to someone else?

AI Collaboration — The next agent reads the handoff. Not the author, not the originating agent — a fresh agent with no prior context. Can it act on the handoff without the conversation?

The community's response is an observation. It goes into the ledger like any other observation — with what was tested, who was in the community, what was observed, and what it implies.

If the community confirms transfer, that's evidence the output works. It strengthens confidence in the decisions that produced it.

If the community surfaces a gap, that's a new constraint. It enters the ledger and informs the next iteration. The loop continues: converse → generate → validate → promote or pivot. Community checking is what makes "validate" honest.

Community checking is distinct from expert review. Experts evaluate correctness. Communities test transfer. Both are valuable. They are not interchangeable.

Community checking results are ledger entries — observations that feed back into the system, not opinions that get discussed and forgotten.

This applies to every vertical, not just translation. Any output intended for an audience needs community checking.

Without community checking, the collaboration loop is incomplete — you can validate output against intent but not outcome against reality.

The author cannot be their own audience. This is not a preference. It is a structural limitation of perspective.

This constraint applies to ODD itself. Until communities beyond the author test ODD and oddkit in their own contexts, the system has validated its outputs but not verified its outcomes. One person using it extensively is an observation — a useful data point, but not community checking. The system's own principles demand this honesty.