The Four-Gates protocol enforces a structure that scripture and long-running boards converge on independently: name what's non-negotiable, name the protective floor, require witness, allow time. The engine refuses to let a decision through without those parts.
The order is fixed: RED → FLOOR → BROTHERS → GOD. You don't get to skip ahead.
Coercion, deception, exploitation, idolatry. Things that cannot be permitted regardless of pragmatic upside. A decision that names these and affirms it does not violate them passes RED. A decision that violates one fails RED, and the engine halts.
Proportionality, accountability, transparency, due process, protection of the vulnerable, basic provision obligations. Below this floor, the decision is unsafe regardless of intent.
"By the mouth of two or three witnesses every word may be established." Witnesses named in the packet, count consistent with declared count. The engine doesn't decide who counts as a witness — the community does — it just enforces the threshold.
"He who is hasty with his feet sins." A wait window proportional to scope: an hour for routine, a day for material, a week for canon-affecting. Buys the space for the still small voice — or for an objection — to surface.
This is software, not authority. The engine enforces rules the community has authored. It cannot substitute for the discernment of elders, the conviction of conscience, or the prompting of the Spirit. It does not adjudicate doctrine, interpret scripture, or judge between competing pastoral approaches.
What it does is prevent the kind of decision that becomes a problem because nobody wrote down who was accountable. That kind of decision is not a wisdom failure — it's a structural failure, and structure is what software is good for.
An elder board is considering reallocating a building-fund line to fund a discipleship intensive. Before voting:
verify_governance_decision_packet({
"title": "Reallocate $30k from building fund to discipleship intensive",
"scope": "canon",
"red_items": ["no coercion of giving",
"no opacity to congregation"],
"floor_items": ["fund balance preserved",
"elder unanimity required"],
"way_path": "Hold reallocation through July; intensive runs Aug-Oct.
Public communication at next congregational meeting.",
"execution_steps": ["Elder vote", "Treasurer transfer",
"Congregational announcement", "Quarterly review"],
"witnesses": ["Elder Smith", "Elder Jones", "Treasurer Davis"],
"elder_signoff": ["Smith", "Jones", "Brown"],
"scripture_anchor": "Acts 6:1-4",
"congregation_impact": "12-week intensive; ~25 households invited"
}, witness_count=3, domain="church")
→ {"shape": {"status": "CONFIRMED"},
"witness_consistency": {"status": "CONFIRMED"},
"domain_profile": {"status": "CONFIRMED",
"detail": "church required + recommended fields all present"}}Now the elders can vote knowing every required structural piece is in place — including the scripture anchor and the congregation-impact note that some boards forget under pressure.
The engine ships in a generic form (RED / FLOOR / BROTHERS / GOD with no doctrinal content), and a community provides the rule set. A reformed church will populate red_items differently than a Catholic parish will — that's correct. The engine's job is to enforce that the rule set is named and the packet is consistent with what was declared, not to write the rules.
For households: the same gates apply with smaller scope. "Should we co-sign for our adult child's car loan?" runs the same RED → FLOOR → BROTHERS → GOD sequence with a household-domain profile (budget category, affected dependents, time horizon, alternatives considered). Most household decisions that go badly fail FLOOR — proportionality or accountability — long before they fail RED.