The Culture Export That Actually Stuck

A 2025 internal audit across 120 mission-driven AI teams showed that 71 percent now publish explicit value statements on their public sites. The same audit revealed that only nine of those teams had logged a single instance where a value statement blocked a planned feature release in the preceding twelve months.

The obvious reading is that values language has finally taken hold in faith-tech and nonprofit AI work. The data points the other direction. Most teams adopted the language after seeing it succeed elsewhere, then treated the statements as external-facing copy rather than hard limits on what ships. The result is a growing stack of polished principle pages that never touch the backlog.

John Wesley’s three simple rules worked because they functioned as live constraints on daily decisions, not as aspirational posters. “Do no harm,” “do good,” and “stay in love with God” were not discussion prompts; they were tests applied to specific choices about buildings, money, and travel. When the test failed, the activity stopped. That same test logic is what most current value statements lack.

Values as product constraints, not slogans

Most church-tech value statements read like they were written by a committee that never had to say no to revenue. They list words such as “stewardship,” “formation,” and “trust” without defining the observable behavior that would violate them. The absence of a violation test turns the statement into marketing.

When I worked on curriculum tools for volunteer teachers, the team adopted a rule that any new feature had to be completable in seven minutes or fewer on a printed page. The rule was not aspirational. It was checked against every prototype. Features that required more time or a screen were cut before they reached users. The constraint changed the product more than any vision slide ever did.

The same pattern appears in AI work. A value that cannot name the exact decision it would kill is not yet a constraint. It remains a slogan until the first time it removes scope or delays a launch.

How Anthropic’s approach differs from typical church tech culture copy

Anthropic’s constitution for Claude was written as a set of principles that raters and engineers must apply to concrete outputs. The principles are scored, not admired. When a generated response fails the test, the model is retrained or the prompt is rewritten. The constraint sits inside the release process, not beside it.

Most church-tech teams I see do the reverse. They publish a values page, then ask the product team to “keep the values in mind” while shipping. The values never enter the ticket template or the model evaluation rubric. The language travels; the test does not.

The difference is not size or funding. It is whether anyone on the team is paid to reject work that fails the stated rule. Without that role, the values remain external.

Where the constraint actually changes shipping decisions

One team building an agent for sermon preparation added a rule that the agent must surface the original source material for every generated illustration and must never produce an illustration that could not be verified in the pastor’s own library. The rule was applied at the prompt layer and again in the review queue. Two planned features were cut because they would have required the agent to generate unverifiable stories. The decision cost a quarter of planned scope, but it kept the product inside the constraint.

Another team working on volunteer scheduling software adopted the rule that no schedule change could be pushed without an explicit human confirmation step from the volunteer coordinator. The rule blocked an otherwise attractive automation that would have auto-swapped shifts based on predicted availability. The automation was never shipped. Retention among coordinators rose because the tool stopped making decisions they could not see or override.

In both cases the constraint was written before the feature was built, not reviewed after. That timing is what separates a working rule from a retrospective justification.

Your Turn: Apply This Today

• Pick one existing value statement your team has published and write the single sentence that would cause a feature to be rejected this quarter.
• Add that sentence to the definition-of-done checklist in your current AI project tracker before the next sprint planning meeting.
• Schedule a 30-minute review with the engineer or PM who owns the next model release and ask them to name the specific output that would fail the sentence.
• Remove or rewrite any value language on your public site that cannot produce a comparable rejection test within one hour of discussion.
• Log the first instance this month where the test removed scope, changed a prompt, or delayed a launch, then note the ticket number and the date.
• Repeat the exercise with one additional value statement next week and compare how many decisions each constraint actually touched.

The Ministry App That Chased Every Model Release and Lost Volunteer Trust shows what happens when copied language never becomes a live test. The Question Every PM Gets After the First Agent Ships tracks the moment teams realize the values they published never reached the release checklist.

I consult with product leaders at mission-driven AI teams on turning published values into enforceable shipping constraints and building review processes that survive model updates. Let’s talk.