Dear Ministry PM who inherited the AI volunteer coordination tool three months after the last lead walked out,
You know the Slack thread is still pinned at the top. The one where the old captain said “we’ll figure out the override rules once the model is live.” You also know the model is live now, and every Tuesday morning three different regional directors are asking why their local kids ministry leads can’t book a room without going through a central queue that no one owns.
That handoff never happened. Not the real one. The one with the frozen inputs, the named signers, and the explicit permission gates. What you got instead was a deck and a login.
This is the foundational misread that causes ministry product teams to decentralize authority without ever building the lattice that makes decentralization work. Charlie Munger’s latticework of mental models only produces better decisions when every node carries explicit constraints and cross-checks. Remove the constraints and you simply multiply the number of people who can approve something without ever seeing the downstream cost.
Map every captain decision to an actual signer
The first place the lattice breaks is when a model output is treated as a completed action rather than a proposed one. On one curriculum platform, an AI tool started auto-generating lesson assignments for volunteer teams. The model had learned from three years of historical data that certain age groups preferred shorter videos. What it had not learned was that one region’s volunteer coordinator had a standing agreement with a local printer for paper versions only. The first time the system pushed digital-only assignments, three churches printed their own copies at their own expense and the coordinator spent the next week fielding complaints.
The fix was not more model training. It was naming the exact person who still held physical permission to change the output format. Once that signer was written into the workflow, the model could suggest, but the assignment only moved forward after the signer confirmed the input constraints had not changed. The queue disappeared because the constraint was now visible and owned.
The same pattern shows up in room booking tools. When the AI proposes a time slot, someone must still be the signer who confirms the room is not already reserved for a funeral or a food pantry distribution that never appears in the shared calendar. Without that named signer, every “autonomous” suggestion eventually lands back in the same review queue, only now the queue is larger and the original captain is gone.
Build the knowledge OS around what cannot be regenerated
Munger’s lattice requires models that cannot be rebuilt from public data alone. In ministry settings the irreplaceable pieces are almost always local relationships and physical constraints. A volunteer’s willingness to teach only on weeks when her husband is not traveling for work cannot be regenerated from usage logs. A church’s rule that the nursery must stay empty during the 8 a.m. service because the carpet is being cleaned cannot be inferred from click data.
The knowledge operating system therefore has to store these constraints as first-class objects, not as footnotes. One team created a simple shared table that every AI suggestion had to query before generating an output. The table contained only three columns: constraint description, current signer, and last verified date. Anything not in the table was treated as unknown and therefore blocked. The model’s suggestions dropped by half, but the acceptance rate on the ones that remained rose sharply because they no longer violated unstated local rules.
Without this layer, decentralization simply accelerates the rate at which bad suggestions reach volunteers. The lattice collapses because the missing nodes are the ones that actually determine whether an action is permissible.
Run the first three loops with the handoff log visible
The first time a new captain runs the system, the handoff log must be public. Not summarized, not archived, but sitting in the same interface where decisions are made. In one deployment the team kept a running document that listed every override, who made it, and what constraint had been missed. After three weekly cycles the document revealed that two regional directors were overriding the same constraint for different reasons. One needed the room for a food distribution that only happened on odd weeks; the other needed it for a counseling appointment that could not be moved. Once both reasons were visible, the model input was updated to treat those weeks as blocked, and the overrides stopped.
Visibility also surfaces when the original captain’s mental model was simply wrong. The log becomes the place where the new captain can see the difference between “this rule was never documented” and “this rule was documented but no longer holds.” Without that distinction the team keeps re-learning the same exceptions at higher speed.
Your Turn: Apply This Today
- Pick the single AI-generated workflow your volunteers interact with most and list every decision the model currently makes without a named human signer.
- For each decision, identify the one person who still holds physical authority to block or alter the output and add that name to the workflow definition this week.
- Create a shared constraint table with only three columns—description, signer, last verified date—and require the model to query it before any suggestion is shown.
- Run the next three decision cycles with a visible handoff log that records every override, the reason given, and the constraint that was missed.
- After the third cycle, update the model inputs with any constraints that appeared more than once in the log.
- Schedule a 30-minute review with the actual signers to confirm nothing in the table has changed since the last verification date.
The same lattice problems appear when AI tools are applied to sermon preparation and children’s ministry resource distribution; the posts on those topics show how the missing permission gates surface in different places but for the same structural reason.
I consult with ministry product leaders on mapping decision signers, building knowledge operating systems around local constraints, and running visible handoff loops in AI deployments. Let’s talk.