I spent a full year insisting that every AI feature decision in our ministry tools had to clear a data threshold first. The rule sounded responsible: no launch without measurable signals on engagement, completion, or retention. In practice it meant we green-lit an automated content generator for children’s ministry volunteers because the early click rates looked promising and the drop-off numbers stayed flat. Six weeks later a volunteer printed a lesson that inserted a theologically sloppy paragraph about grace, and a parent called the church office confused and angry. The damage was small but real, and it happened because I had treated the absence of negative data as permission to skip the judgment step. That year taught me a hard lesson about ministry judgment calls: data can inform them, but it can never replace them.
That choice cost us trust with two ministry teams and forced a rushed rollback that burned engineering hours we didn’t have. More quietly, it taught the product group that metrics could substitute for deciding what actually protects children and the people serving them. I had confused “we have no evidence of harm” with “we have exercised wisdom.” I had let metrics quietly absorb the ministry judgment calls that should have stayed human.
The inbox that taught me ministry judgment calls first
The children’s director’s inbox had always been the real spec. Every week it contained the questions that data never captured: “Will this lesson still work if the volunteer only has seven minutes between services?” “What happens when a ten-year-old asks the follow-up question the script doesn’t cover?” Those messages forced a kind of judgment that treated edge cases as primary, not anecdotal.
When we moved the same team onto an AI-assisted outline tool, the inbox went quiet for three weeks. The numbers looked clean, so we kept shipping. Only later did we learn the volunteers had stopped asking questions because the generated outlines felt finished. They were also quietly correcting the theological shortcuts on their own time. The cost showed up later in volunteer burnout, not in the dashboard.
Solomon’s judgment in the disputed-infant story worked because he refused to accept the data of two living claimants at face value. He forced a test that revealed what each woman was actually willing to protect. The story is not about gathering more information; it is about constructing a situation that makes the real commitment visible before harm occurs.
How data-first habits quietly hand off ownership
Product teams that default to data thresholds train themselves to outsource the hard calls. Once the threshold is met, the decision feels mechanical. In faith contexts this creates a slow transfer of authority from the people who carry the mission to the people who can move the metric. The AI feature that generated small-group questions looked safe because completion rates held steady, yet no one had asked whether the questions still required a leader who could recognize when someone in the room was in actual crisis. Research on how leaders weigh evidence shows why ministry judgment calls still need a human in the loop.
The pattern repeats across tools. A prayer-request classifier gets approved because precision and recall numbers clear the bar. No one tests what happens when the model routes a disclosure of abuse to the wrong staff member because the training data never included that edge. The data did its job; the product organization had already decided its job was finished once the numbers cleared.
This is the move Solomon refused. He did not wait for additional evidence to accumulate; he acted on the judgment that protecting the child mattered more than preserving the appearance of fairness between two claimants. Data-first cultures lose the muscle for that kind of preemptive decision.
Rebuilding ministry judgment calls into every AI pilot
The fix is not to ignore data. It is to insert an explicit judgment gate before any pilot leaves the internal environment. The gate requires naming the specific person or group whose safety or formation could be damaged if the model behaves as designed. That naming happens in writing and must be signed by someone whose role includes ongoing responsibility for the people being served.
Next comes a forced negative test. The team must articulate the scenario in which the feature succeeds on metrics while still violating the named commitment. Only after that scenario is written and reviewed does the pilot move forward. The test is not optional and does not require statistical significance; it requires the same kind of clarity Solomon demonstrated when he identified what the two women were actually willing to lose.
We now run this gate on every new AI capability in the curriculum tools. The process adds two days to the start of a pilot and removes entire categories of later rework. It also surfaces questions the data never would have asked, such as whether an AI-generated illustration for a children’s lesson should be allowed to depict Jesus in a way that contradicts the visual language already used by the volunteer’s own church.
Your Turn: Apply This Today
- Pick one active AI feature and write the single sentence that names the exact person whose formation or safety could be damaged if the model performs as designed.
- Schedule a thirty-minute meeting this week with the ministry owner who carries real responsibility for that person; read the sentence out loud and ask them to revise it until it matches their actual stakes.
- Before the meeting ends, draft the one negative scenario in which the feature meets its current success metrics while violating the commitment you just named.
- Block two hours next week to run a manual test of that scenario with three real users who match the edge case, not the average user.
- Write the decision that follows the test in one paragraph and send it to the same ministry owner for sign-off before any further engineering work proceeds.
- Document the entire exchange in the project log so the next team cannot claim they lacked the judgment step.
The same pattern of deferred judgment shows up in how mid-career product managers track the wrong signals and how children’s directors end up owning the actual product requirements without anyone noticing. Both posts trace what happens when teams treat external proof as a substitute for deciding what must be protected.
I consult with AI product leaders and ministry technology teams on judgment gates for early pilots, metric design that respects edge cases, and rebuilding ownership after data-first habits have taken hold. Let’s talk.