The first piece in this series considered the user, the person directing the system. The second considered the subject, the person a system observes, classifies, or creates knowledge about. This piece turns to the source, the person whose writing, images, data, judgment, experience, or ideas become part of what the system can do.

When you’re the subject, the system creates knowledge about you. When you’re the source, it creates value from something you contributed. Often, you are both. The participant in a focus group may become the subject of an analysis while also supplying the stories that make the analysis possible. Someone using a chatbot may be the user during the conversation, then become a source if that interaction is retained and used to improve the product.

The category is broad because AI depends on many kinds of human contribution. A novelist, a programmer, an employee uploading organizational documents, a researcher publishing findings, and a community sharing its experience do not have the same rights or occupy the same position. Still, they share one important feature: the system becomes more useful because of something they supplied.

AI does not learn from nowhere, even when the people it learned from have disappeared from view.

When sharing only moves one way

I have been circling this problem for a while through my writing on data sovereignty. In AI Governance Has a Thanksgiving Problem, I used the familiar Thanksgiving story to think about the way extraction gets described as collaboration. The story presents a shared table and mutual exchange while obscuring what was taken, who benefited, and what happened afterward.

AI governance has developed its own version of that story. We say a model learned from the internet, data was publicly available, users helped improve the product, or communities contributed their knowledge. The language makes the relationship sound mutual, but following the value tells a different story. The company gains a more capable model, the organization produces a report, the evaluator gets paid, and the user receives an answer. The people whose knowledge made those things possible may receive very little, and they may not even know they participated.

As I wrote in that earlier piece, “The table was built from what was taken, and the feast is made of it.”

That does not make every use of existing knowledge an act of theft. People have always learned from one another, adapted methods, cited previous work, and combined old ideas into new ones. Shared knowledge is a public good, and AI can help us find, translate, connect, and apply it in ways that are genuinely useful. I use AI for exactly those reasons.

The problem begins when we call something sharing without asking whether the relationship runs in both directions.

In Whose Data Is It, Anyway?, I described how information usually moves through the social sector. Communities supply experiences, outcomes, and stories. Organizations collect them, evaluators turn them into findings, and funders receive the resulting reports. Data and value travel upward, while very little returns to the people who supplied the original knowledge.

Nobody has to set out to exploit anyone for this to happen. The consent forms can be signed, the data can be de-identified, and the servers can be secure. Everyone involved can follow the approved process with reasonable care, while the people at the beginning of the process retain no authority over what their contribution becomes. Extraction does not always require a villain. Sometimes it only requires a system whose defaults point in one direction.

Sovereignty is about authority

This is where data sovereignty changes the question.

Privacy asks whether information is protected. Security asks who can enter the system. Access asks whether someone can retrieve the data. Sovereignty asks who has the authority to decide what happens to it.

The First Nations principles of OCAP® name ownership, control, access, and possession as connected forms of authority over First Nations data. OCAP® is not a generic framework that can simply be lifted out of its political and historical context. It applies specifically to First Nations, whose sovereignty is a legal and political reality; not a metaphor for feeling respected.

The CARE Principles for Indigenous Data Governance similarly ask whether data practices produce collective benefit, recognize authority to control, fulfill responsibilities to the people represented, and meet ethical obligations throughout the life of the data. These principles emerged from particular histories in which Indigenous peoples were intensely studied while receiving little benefit and retaining little authority over the knowledge extracted from them.

A writer, employee, or chatbot user does not occupy the same position as an Indigenous nation, and I do not want to flatten those differences. What these frameworks expose, however, is the weakness of a model built entirely around individual consent and technical protection. A person can sign a form and still have no meaningful ability to object later. A community can receive access to a dataset without receiving anything it can use. Information can be protected inside a system that the people who supplied it never wanted it to enter.

In AI Governance From Below, I argued that community data should not become the unrestricted property of an organization simply because the organization collected it. AI makes that principle more important because it expands the number of possible future uses. An interview collected for an evaluation can become input to an organizational chatbot. A set of case notes can become training material. Community language developed for one report can reappear in grant proposals, strategy documents, or products that no one imagined when the information was first provided.

The usual question is whether the organization obtained the data legally. The sovereignty question goes further by asking who retains authority over what the data may become.

The sources inside my own work

I am encountering a smaller version of this problem while building the Conditions Web, an AI-guided conversational process that helps social impact organizations examine the conditions surrounding their work before developing a strategy or evaluation. Rather than beginning with a linear logic model, it maps historical, social, organizational, political, economic, cultural, and place-based conditions as an interconnected web.

I designed the particular structure, decided how its domains relate to one another, and developed the process through which a conversation becomes something an organization can use. I believe the synthesis itself has value, but I did not invent all the thinking inside it. The Conditions Web draws from ideas that have evolved across evaluation and systems practice for decades, including developmental evaluation, contribution analysis, participatory evaluation, systems thinking, empowerment evaluation, the Zen business model, and work on power, context, complexity, and unintended consequences.

Some of those ideas are associated with particular scholars and practitioners, while others grew through communities of practice and do not belong neatly to one person. Either way, the framework has an intellectual lineage, and the people within that lineage are sources.

I plan to publish the people behind the framework alongside the framework itself. It will work something like a bibliography, but I want it to do more than list publications. I want to explain what each person or body of work contributed, where someone can find the original thinking, and how I have borrowed, combined, modified, or departed from it.

The language used to describe those relationships matters. Created by, adapted from, influenced by, and consistent with are not different ways of saying the same thing. They tell the reader how close the relationship is and where my contribution begins.

Making that lineage visible is partly about giving credit, but it is also about making the Conditions Web easier to question. Someone who can trace an idea back to its source can read the fuller argument, examine my interpretation, and decide whether I used it well. A visible lineage makes a framework less magical and more accountable because it shows that the authority inside the tool came from somewhere.

It also makes clear that the AI did not invent the framework. AI may guide a conversation or help synthesize what a user says, but the ideas organizing that process came from people who spent years working through real problems. I am not outside the source question simply because I recognize it. I am building something that creates value by combining other people’s thinking, which means I have obligations to those people as well as to the eventual users.

The questions changed the tool

Writing down these obligations forced me to turn them back on the Conditions Web. The intellectual bibliography I had planned still mattered, but it only addressed the people whose ideas shaped the framework. It did not address the people and communities who will contribute knowledge while using it.

Those are different source relationships, and they create different obligations. A scholar whose published work influenced the methodology should be accurately credited, with permission sought when I reproduce protected language, diagrams, instruments, or proprietary methods. A participant describing the conditions in their community needs something more. They need to know how their contribution will be processed, retain some authority over its use, see what the system made from it, and receive something useful in return.

I have now written that distinction into the Conditions Web’s intellectual lineage and methodology. Before the tool invites direct participation, it must explain whether contributions reach a third-party AI provider, what is retained, and whether Anthralytic or the provider uses submissions for product improvement or model training. Any use for improvement or training must require separate consent rather than being bundled into ordinary use.

Participants must also be able to choose how they are identified and place limits on how a particular contribution may be analyzed, quoted, shared, or reused. Their original account should remain connected to anything Q synthesizes from it, and the system should make clear when Q has drawn an inference that nobody actually stated. Participants should be able to correct or withdraw what they contributed, with that decision carried through the conditions, relationships, summaries, and exports derived from it.

Most importantly, participation cannot remain another one-way data collection exercise. People who contribute knowledge should have an opportunity to review how they were represented and receive the result in a form they can actually use. That might be a readable summary, a relevant portion of the web, or another return agreed upon in advance. The organization commissioning the work should not be the only party that benefits.

The same principle changes how organizational documents enter the system. Conditions Web will ask whether the person uploading a document has permission to use it in an AI-assisted analysis. Possessing a file does not necessarily create authority to reuse everything inside it, especially when it contains material written by employees, partners, clients, or community members for another purpose.

I also added these obligations to the product’s evaluation rubric. Disclosure, contribution-level permissions, correction, withdrawal, participant validation, reciprocal return, upload authority, and the distinction between citation and permission are now release checks. If the product cannot meet them, that part of the experience should not be treated as ready.

This does not mean the problem is solved. Writing a requirement is easier than building it, and building a control is easier than knowing whether it works for the people it is intended to protect. The next step is implementation and testing with people whose knowledge the Conditions Web will ask them to share.

Still, the questions have already changed what I am building. They led me to a standard that is stronger than simply saying users own their data:

Anyone whose knowledge enters the Conditions Web should be able to understand how it will be used, see how it was represented, challenge what the system made from it, and receive something useful in return.

That is what sovereignty begins to look like inside a product. It is not only ownership language in a privacy policy. It is authority made visible through the design.

AI can help us build from what people know, and that is part of its value. The test is whether doing so requires making those people disappear. When you are the source, safety means retaining some authority over what your contribution becomes, receiving something meaningful when value is created from it, and remaining visible inside the systems you helped make useful.

Anthralytic helps mission-driven organizations use strategy, evaluation, data, and AI to understand their impact and make better decisions.

OCAP® is a registered trademark of the First Nations Information Governance Centre.

The first piece in this series focused on the user, the person sitting in front of the screen. As users, we can decide what to ask, what to share, how carefully to check the answer, and how much authority to give the system. Those choices do not eliminate risk, but they give us some agency.

The second position is different. You become the subject when an AI system is not working for you but is being used to observe, classify, predict, rank, or create knowledge about you. Someone else chooses the system and controls how it is used. You may never see the interface or even know that the system exists.

That difference becomes especially clear with Flock cameras.

Flock Safety operates a large network of automated license plate readers. Police departments and other organizations use the cameras to capture license plates, vehicle characteristics, time, and location. These systems can serve legitimate public purposes. Departments use them to investigate crimes, locate stolen vehicles, and search for missing people. An Associated Press overview of Flock captures both their usefulness and the concerns surrounding their rapid expansion.

But the police department is the user. The person driving past the camera is the subject. Flock often refers to its customers as “communities.” But in this context, the customer is usually a police department or another organization operating the cameras. The people whose movements are being recorded are part of the community too, yet they do not control the system or the data it creates.

That distinction matters. Saying that a community controls its data suggests a degree of shared public agency that may not exist. In practice, control sits with the institution that purchased the system, while many of the people represented in the data had no role in choosing it or establishing its limits.

That person did not choose the system. They may not know where the cameras are, how long the information is retained, who can search it, what other information it can be combined with, or where it may travel next. They may have done nothing wrong and may never be investigated, but a record about their movements has still been created.

This is not mainly a story about whether a camera can read a license plate correctly. It is a story about what happens after that observation becomes data.

The power is in the join

I see the power of linked data every day in my work. A single dataset usually gives you one narrow view of a person or a program. When you connect datasets, you can begin to see patterns that were previously invisible.

That can produce real public value.

Rhode Island, for example, connected information from developmental screenings, early intervention, health programs, early childhood care, and education. Linking those records allowed the state to ask whether children who failed developmental screenings were referred, evaluated, and connected to services. It could also examine whether children who were missed later required special education.

None of the individual datasets could answer those questions alone. The insight came from the join. The goal was not simply to collect more information. It was to understand where children were falling through the cracks and improve how public systems served them. The federal government’s report on integrating early childhood data also describes safeguards including parental notice, opportunities to opt out, controlled access, and formal data-sharing agreements.

The same principle applies to surveillance data.

One observation of a license plate at a particular time and place may not reveal very much. A series of observations can begin to show a routine. Combine those observations with vehicle registration, home addresses, police records, commercial information, or other location data, and the system may be able to infer where someone lives, works, worships, receives medical care, or spends time with other people. The Electronic Frontier Foundation’s overview of automated license plate readers explains how aggregated location records can reveal far more than an isolated photograph.

The join is not inherently good or bad. The Rhode Island example shows how linked data can help institutions identify gaps and improve services. The Flock example shows how the same capability can create knowledge about people who have little visibility into the process.

The difference lies in purpose, safeguards, and agency.

What we know and what we cannot see

Concerns about Flock often become entangled with Palantir because there is a real financial connection between the companies, although it is important to describe that connection accurately.

Peter Thiel co-founded Palantir and remains its chairman. He is also a partner at Founders Fund, which has invested in Flock and participated in its 2025 funding round. Palantir builds software designed to integrate and analyze information from many different sources. Its own materials describe Foundry as a platform for connecting data across systems.

That connection is worth noticing because it illustrates the growing ecosystem around government and surveillance data. It is not, however, evidence that Flock is sending data directly to Palantir.

Flock says that it does not work with Palantir, that Palantir has no access to its customer data, and that Flock data is not shared with Palantir. I have not found public evidence of a direct Flock-to-Palantir feed.

The problem is not that we should assume a secret connection. The problem is that an ordinary person has no practical way to see every search, export, integration, derived record, or downstream use involving data about them and must trust that Flock and Palantir are operating in the interest of the common good. Evidence may eventually surface through contracts, audit logs, public-records requests, litigation, investigations, or required disclosures. But those are not routine, subject-facing forms of accountability.

We already know that data can move beyond the context in which people assume it is being collected. The Associated Press reported that Border Patrol previously had access to data from at least 1,600 Flock readers across 22 states. Some local agencies also reportedly conducted searches on behalf of federal authorities.

This does not prove that every department is misusing its system. It does show why “our police department owns the data” is not a complete answer. Access can expand through sharing arrangements, regional networks, exports, integrations, and requests from other agencies.

Public safety requires public trust

Flock cameras are generally purchased in the name of a public good: safer communities, faster investigations, recovered vehicles, missing people found, and serious crimes solved. Those benefits matter. It would be too easy to dismiss them or pretend that communities do not have real safety problems they want public institutions to address.

But the public good cannot be defined only as the institution’s ability to collect more information or solve cases more efficiently. It also includes civil liberties, equal treatment, freedom of movement and association, and confidence that public power is being used within limits.

Trust is part of that public good.

Public trust does not mean asking people to take an agency’s assurances on faith. It comes from being able to form reasonable expectations about what an institution will do, seeing evidence that the rules are being followed, and having somewhere to go when they are not. The NIST AI Risk Management Framework treats transparency and accountability as foundations of trustworthy systems, including for people who may not even realize they are interacting with one.

This matters because the relationship between a public agency and a resident is not the same as the relationship between a company and a customer. A resident cannot simply choose another police department. In many cases, they cannot avoid the system, decline its terms, or remove themselves from its dataset.

That means a procurement decision can also be a public policy decision. Buying the technology determines what the government will be capable of knowing, whom it can monitor, which other institutions can gain access, and how long those capabilities may persist. If those decisions happen primarily between a vendor and a police department, the people who will become the subjects are left out of deciding what the public good requires.

A system can produce useful results and still damage trust if people believe its reach is hidden, unlimited, or impossible to challenge. Once that trust is lost, publishing another reassurance may not repair it. Institutions have to show that boundaries exist before a controversy exposes how weak they were.

The agency gap

The central problem is not simply data collection. It is the distance between the power of the system and the agency of the person described by it.

The NIST Privacy Framework offers two useful ideas for thinking about this. The first is predictability, or whether people can form reasonable expectations about how their data will be used. The second is manageability, or whether they have any ability to alter, delete, limit, or selectively disclose that information.

A person driving past a Flock camera may have neither. They cannot reasonably predict every future use of the record, and they cannot meaningfully manage it. They may also lack notice, access, an opportunity to correct an error, or a way to challenge a harmful use.

For public systems, those protections cannot depend entirely on individual action. Most people do not have the time or expertise to file records requests, investigate vendor contracts, and interpret data-sharing agreements. The responsibility has to sit with the institutions choosing and governing the technology.

Residents, journalists, elected officials, oversight boards, and public employees can still push for specific answers:

• What public problem is this system meant to solve, and how will success be measured?

• What information is collected, and how long is it retained?

• Who can search the system, and what reason must they provide?

• Which agencies, vendors, and other organizations can receive the data?

• Can the information be linked with other datasets? If so, which ones and for what purposes?

• Are all searches, exports, and sharing requests logged and independently audited?

• What happens when someone misuses the system?

• Can a person learn whether inaccurate data affected an investigation or decision and have it corrected?

• Will the agency publish aggregate statistics about searches, matches, sharing, violations, and outcomes?

Those questions only matter if the answers become enforceable rules. That can mean retention limits, written search standards, restrictions on data sharing, public reporting, independent audits, contract provisions, penalties for misuse, and expiration dates requiring a system to be reconsidered rather than renewed automatically.

The goal is not to prevent government from using useful technology. It is to make sure that usefulness is judged alongside the rights of the people who supply the data simply by moving through public space.

When someone else is the user

Flock cameras are one example of what it means to be the subject of an AI or data system. The same position appears when software analyzes an employee’s productivity, predicts a family’s risk, ranks a student, flags a benefits application, estimates a patient’s future behavior, or uses online activity to infer something a person never directly disclosed.

In each case, the institution is the user. The person being described is the subject.

The safety question is therefore larger than whether the system works as designed. We also have to ask who can see what it is doing, who receives the benefit, who carries the risk, and whether the people affected have any meaningful voice in setting the rules.

A join creates new knowledge, and new knowledge creates power. When that power is exercised by a public institution, public trust cannot be treated as an obstacle to efficiency. It is one of the outcomes the system should be designed to protect.

The power is in the join. Safety depends on whether that join serves a publicly defined good and whether it is visible, limited, auditable, and open to challenge.

Subscribe now

Leave a comment

Share

Anthralytic, I helps organizations use data and AI to solve real problems without losing sight of the people represented in the data. Through consulting and practical digital tools, I help teams build systems that are useful, responsible, and worthy of public trust.

I am guilty of nearly everything I am about to warn against.

I get lazy and write an ambiguous prompt. I leave out context. I barely think through what I want before asking AI to produce it.

And often, the output is great.

Sometimes I get back something so useful that it feels as if I did more thinking than I actually did. The system takes a half-formed idea and turns it into an organized plan, a polished draft, or a solution I can immediately use.

That is not a failure. It is one of the most valuable things about generative AI.

These systems are getting better at interpreting incomplete instructions and predicting what we probably mean. As that improves, we will be able to accomplish more with less effort. People who struggle with writing, organization, language, or getting started may benefit enormously.

Still, I think it is worth noticing what happens when the system gets good enough to fill in all the gaps for us.

Every time AI frames the problem, chooses the structure, writes the first draft, and supplies the conclusion, we skip some of the mental work that would otherwise happen along the way. Sometimes skipping that work is the entire point. Sometimes it is how we save time.

But if we skip it every time, certain skills may begin to atrophy.

That does not mean we should stop using AI. It means we should occasionally pause and do something ourselves, even when the tool could do it faster. Write the paragraph. Sketch the plan. Work through the problem. Sit with the blank page for a few minutes.

Not because using AI is cheating, but because judgment needs exercise.

Know when ambiguity is useful

Advice about prompting often focuses on specificity. Define the role, provide context, describe the format, list the constraints, and explain exactly what you want.

That advice is useful when you need a predictable result. It is not a rule for every interaction.

An ambiguous prompt can be productive when you are brainstorming or exploring. It gives the system room to surprise you. You may discover an interpretation or direction you would not have considered on your own.

The issue is not ambiguity itself. The issue is whether the task can safely absorb it.

If you are generating names for a project, an unexpected answer may be interesting. If you are asking an AI to send an email, change a record, spend money, or advise you on something consequential, ambiguity carries more risk.

Before prompting, it helps to decide what kind of task this is.

Are you exploring, drafting, deciding, or acting?

Exploration can tolerate uncertainty. Action usually requires clearer boundaries.

If I ask an AI to “handle my trip,” it might reasonably interpret that as researching flights, comparing hotels, checking my calendar, or booking a ticket. The phrase feels obvious to me because I know what I meant. The system has to infer it.

A better instruction might be: compare three flights within this budget, but do not book anything.

That still saves time. It also keeps the decision where I intended it to stay.

Do some of the thinking before you prompt

One of the easiest ways to preserve your own judgment is to give yourself a short head start.

Before asking AI to write something, jot down what you think. Before asking it to solve a problem, make your own rough attempt. Before asking for a recommendation, identify the factors that matter to you.

This does not need to take long. Even a few minutes can change the interaction.

When you begin with your own position, AI becomes something you can compare your thinking against. You can see where it adds value, where it challenges you, and where it pulls the work in a direction you do not agree with.

When the AI always goes first, its framing can quietly become your framing.

This matters because the first plausible answer often shapes everything that follows. Once a structure appears on the page, it is easy to edit within it rather than question whether it was the right structure in the first place.

I do not think every email, summary, or routine task deserves deep independent thought. Offloading low-value work is part of the benefit. The point is to keep practicing the skills you want to retain.

If writing matters to you, do some writing before you prompt.

If analysis matters to you, sometimes form a view before asking for one.

If a decision matters to you, decide what you value before asking the system what it recommends.

The NIST Generative AI Profile includes human overreliance among the risks organizations should consider. From the user’s perspective, the practical concern is not that AI will suddenly eliminate our ability to think. It is that convenience can gradually change which parts of thinking we continue to practice.

Give it the context it needs

AI often works better with context. That does not mean it needs every piece of context you have.

If you want help summarizing a document, the system may not need names, account numbers, addresses, or client information. If you want help with your schedule, it may need your availability without needing the details of every calendar event.

Before uploading something, ask:

Does the AI need all of this to complete the task?

Often, the answer is no.

You can remove identifying details, replace names with placeholders, share an excerpt instead of a complete file, or describe the situation without uploading the original material.

It is also worth reviewing which services your AI tools can access. An integration that was convenient months ago may no longer be necessary. Disconnecting unused accounts reduces the amount of information any one system can reach.

The NIST Privacy Framework treats privacy as more than preventing a data breach. Data use can also affect autonomy, reputation, opportunity, and trust.

For an individual user, the practical lesson is simple: share what the task requires, not everything the system is willing to accept.

Check the things that matter

AI does not have to be perfect to be useful.

If you are brainstorming or looking for a starting point, a strange suggestion may be harmless or even helpful. The calculation changes when the answer will influence your health, finances, work, legal obligations, security, or reputation.

A polished response can still contain a false date, an invented quotation, a faulty calculation, or a source that does not support the claim attached to it.

Verification should rise with the stakes.

For something important, open the sources. Check the publication dates. Confirm names and quotations. Recalculate the numbers. Test the code somewhere safe. If the decision requires professional judgment, talk to a qualified person.

Pay particular attention to citations. Sometimes an AI will invent a reference. Other times it will give you a real source that says something different from what the AI claims. Always ask for links, click them, and read the material. Is this really what you are looking for? Is it helpful? Did the model only give you things to substantiate your claims?

Fluency makes an answer easier to accept. It does not make the answer more accurate.

Use the output as material for your judgment, not as a substitute for it.

Keep control of what the system can do

There is a meaningful difference between an AI that advises you and one that acts for you.

A chatbot can suggest an email. An agent may be able to send it. A planning tool can compare products. An agent may be able to buy one. A coding assistant can recommend a change. An agent may be able to edit the files and deploy them.

These capabilities can save real time. They can also turn a small misunderstanding into an immediate action.

When an AI can send messages, spend money, change records, or access other services, use settings that limit its reach.

Preview actions before they are completed. Confirm the recipient, price, destination, and scope. Set spending limits. Restrict which accounts and tools the system can access. Review its activity history.

Start with small, reversible tasks. See how the system behaves before giving it more authority.

An AI agent may also read webpages, emails, or documents containing instructions that did not come from you. OWASP’s guidance for large language model applications identifies prompt injection and excessive agency as important security risks.

In plain language, the system can encounter content that tries to manipulate what it does. Narrow permissions limit the consequences if it follows the wrong instruction.

You do not need to avoid AI agents. Just do not give them access to everything simply because the setup screen makes it easy.

Make sure there is a way back

Before using AI for something important, ask whether the result can be corrected. What is the worst that could happen if it got something wrong?

Keep an original copy of documents before allowing an AI to revise them. Use version history. Test generated code before it reaches a live system. Review cancellation policies before allowing an assistant to make a reservation or purchase.

Know how to disconnect the tool from your accounts. If it can take actions for you, check whether it keeps a record of what it did.

Planning for recovery is not pessimistic. We already do this with technologies we trust. We save documents, back up photos, review bank statements, and keep spare keys.

Those habits do not keep us from using the tools. They make the tools easier to trust.

This is not all on the user

There are limits to what any individual can do.

A user cannot audit a model they cannot inspect. They cannot create a rollback feature the product does not provide. They cannot turn a buried disclosure into meaningful consent.

Companies still have a responsibility to provide safe defaults, understandable explanations, limited permissions, accessible controls, reliable recovery, and human support.

The NIST AI Risk Management Framework treats AI risk as an organizational responsibility involving governance, assessment, measurement, and continuous management. That responsibility should not be pushed onto the person at the keyboard. Let’s keep pressure on the companies that produce these models, the thought leaders in the space and the legislators that write policies.

Good product design and thoughtful user habits reinforce each other. We need both.

Take a moment

Before you ask AI to do something that matters, pause for a moment.

Ask yourself:

• Have I thought about what I actually want?

• What information does the system need?

• Am I exploring, drafting, deciding, or acting?

• How will I check the result?

• Can I undo what happens next?

Then, every so often, do the task yourself.

Write something without asking AI to begin it. Work through a problem before requesting the answer. Make a decision before asking for a recommendation. And, every once in a while, do the task without AI. Write a report or an essay without it, look through the Excel formulas yourself. Make sure your brain doesn’t atrophy.

You may still prefer what the AI produces. Often, I do.

The point is not to prove that you can outperform the tool. The point is to make sure the tool is extending abilities you still possess.

AI is going to get better at predicting what we mean. That will be useful, convenient, and sometimes remarkable.

Our job is to make sure convenience does not quietly become dependence, and that assistance does not replace the pause in which our own judgment forms.

Next: The Subject, When AI Is About You

Leave a comment

Share

Subscribe now

Anthralytic is a social impact and evaluation studio creating software and offering consulting to help mission-driven teams do what they do well, even better.

It began as an attempt to gather the many dimensions of AI safety into one place: governance, privacy, security, accessibility, testing, human oversight, incident response, worker protection, and the safe retirement of systems that have reached the end of their useful lives.

The framework draws primarily from the NIST AI Risk Management Framework, its Generative AI Profile, and ISO/IEC 42001, the international standard for organizational AI management systems. It also incorporates principles from the EU AI Act, which establishes legal obligations based on the risks associated with different AI systems.

AI does not exist separately from software, data, or the people expected to use it. For that reason, I have also drawn from the NIST Cybersecurity Framework 2.0, the NIST Secure Software Development Framework, the NIST Privacy Framework, the Web Content Accessibility Guidelines, and OWASP’s security guidance for large language model applications.

This is not a new official standard, and it is not intended to replace any of those sources. It is a practical synthesis: a way of organizing the questions I believe teams should answer from the moment an AI system is proposed through its development, deployment, operation, and eventual retirement.

It is also deliberately a living framework. No checklist can anticipate every product, population, jurisdiction, or emerging harm. Safety has to be managed continuously as models, data, integrations, users, and circumstances change.

But as I worked through the framework, one question kept pulling everything else into focus:

Who, exactly, are we trying to keep safe?

The person at the screen is only the beginning

The obvious answer is the user.

When we picture AI safety, we tend to picture someone sitting in front of a screen. Will the chatbot give them a dangerous answer? Will the assistant expose their private information? Will an agent send a message, spend money, or delete something without meaningful authorization?

These are important questions. But the person at the interface is only one point in a much larger human system.

There is also the applicant being ranked by an algorithm, the artist whose work entered a training set, the moderator filtering disturbing material, the employee working under automated surveillance, and the stranger harmed by a deepfake they never consented to and may never see.

A person can be affected by an AI system without purchasing it, operating it, understanding it, or even knowing it exists.

Those people do not stand in the same relationship to the technology. They do not face the same risks, possess the same information, or have the same ability to walk away. Treating all of them as “users” conceals the differences that matter most.

I have come to think of people as occupying five broad positions around an AI system:

• The user interacts with it.

• The subject is evaluated, ranked, monitored, or acted upon by it.

• The source provides the data, identity, behavior, or creative work from which it learns.

• The worker builds, trains, moderates, operates, supports, or works under it.

• The public lives with consequences that extend beyond the product and its customers.

These are not five fixed types of people. They are positions, and one person may occupy several at once.

An employee might use an AI assistant while also being evaluated by an automated performance system. Their communications may become a source of training or monitoring data. Their job may change because of the technology. Outside work, they remain a member of the public exposed to AI-generated fraud, misinformation, and systemic failures.

Where someone stands matters. But position alone does not tell us enough.

Position, proximity, and power

I want to examine each of these relationships through three questions.

Position: How does this person relate to the system?

Are they using it, being judged by it, supplying its data, performing the labor behind it, or encountering its wider effects?

Proximity: How directly and quickly can its consequences reach them?

An incorrect restaurant recommendation and an incorrect medical recommendation may emerge from similar technical behavior, but they do not create the same exposure. Neither do a private drafting error and an automated action executed across thousands of accounts.

Power: Can the person understand, refuse, correct, appeal, or escape what the system does?

Power may be the most important of the three. The same error means something very different to a customer who can close an app than to an applicant who is silently rejected, a worker who cannot refuse workplace surveillance, or a patient who has no alternative source of care.

This is also why vulnerability should not be treated as a separate category of person. Vulnerability can emerge within any of the five positions. Age, disability, language, literacy, crisis, economic dependence, and institutional authority can all change someone’s exposure and their ability to respond.

A person does not need to be inherently vulnerable to be placed in a vulnerable position.

A human map of AI safety

This series will explore AI safety from each of these five positions.

The first piece will consider the user and ask whether interacting with an AI system amounts to meaningful understanding or control.

The second will examine the subject: the person who is screened, scored, monitored, or judged by a system they may never see.

The third will focus on the source and the continuing obligations organizations acquire when human lives and creative work become data.

The fourth will turn to the worker and the labor, surveillance, responsibility, and displacement hidden behind the language of automation.

The final piece will consider the public: people and communities exposed to consequences despite never choosing to participate.

The framework will remain underneath the series. Its provisions on governance, privacy, security, fairness, accessibility, testing, monitoring, redress, vendor risk, and retirement provide the practical tools. The NTIA’s work on independent AI accountability, the FTC’s guidance on manipulative interface design, and UNICEF’s guidance on AI and children help extend those tools into questions of organizational power, consumer autonomy, and child-specific protection.

But instead of approaching all of this from the perspective of the organization, the series will ask what safety means from the position of the people the organization is responsible for protecting.

What can they see?

What can they lose?

What choices do they genuinely possess?

What can they do when the system is wrong?

AI safety cannot be judged only from the seat of the customer the product was built to serve. It must also be judged from the positions of those the system observes, evaluates, learns from, relies upon, and places at risk.

Before we ask whether an AI system is safe, we need to ask:

Where are people standing when it reaches them?

Leave a comment

Share

Subscribe now

Anthralytic is a social impact strategy studio helping mission-driven organizations hone their social transformation through digital tools, including AI, safely.

Framework resources

• NIST AI Risk Management Framework

• NIST Generative AI Profile

• ISO/IEC 42001: AI Management Systems

• European Union Artificial Intelligence Act

• NIST Cybersecurity Framework 2.0

• NIST Secure Software Development Framework

• NIST Privacy Framework

• Web Content Accessibility Guidelines 2.2

• OWASP Top 10 for LLM Applications

• NTIA AI Accountability Policy Report

• FTC: Bringing Dark Patterns to Light

• UNICEF Guidance on AI and Children

I am conducting a short research project to understand where this process breaks down and what could help.

I also designed the survey a little differently. You can answer by typing, or you can let an AI-generated voice guide you through it. The survey reads each question aloud, listens to your spoken answer, and creates a transcript. It feels more like a short research conversation than a standard form. I have not seen many surveys work this way, and I would love for you to check it out.

Take the Survey!

What I want to learn

I want to hear about a real decision that needed data or evidence:

● What were you trying to decide?

● What information did you have or need?

● What made the process difficult?

● What did you ultimately do?

● What has your organization already tried, and how well is it working?

● When does investing in evidence feel worthwhile, and when is it hard to justify?

I have seen a gap between how this work is described and how it happens in practice. In a toolkit, data is available, indicators are clear, and findings arrive in time to shape the next decision.

Inside an organization, information may live in several places. Staff may be stretched thin. Spending on evidence and evaluation may be hard to justify when the same money could support programs, services, or grantmaking.

I do not want to assume that I know where the real difficulty sits. I want to learn from what people are actually experiencing.

How Anthralytic fits

The survey will also help me understand whether there is a real appetite for Anthralytic.

Anthralytic is being created to make experienced social impact strategy accessible to resource-constrained organizations without requiring a large evaluation team or an expensive consulting engagement. It is intended to help organizations clarify strategy, bring together data and people’s knowledge, identify the evidence they need, learn from results, and make better decisions.

That is the honest reason I am doing this research. I would rather build around real problems than problems I have assumed people have.

Who should take it

Anyone who works at or with a nonprofit, foundation, social venture, public agency, intermediary, or another mission-driven organization and has a view into how important decisions get made.

You do not need to be an evaluator, control a budget, or speak for your entire organization. I am interested in your perspective based on what you see and experience.

Before you begin

● The survey takes about 10 minutes.

● You can type your answers or use the voice-guided experience.

● Please share as much as you would like. More context is helpful.

● Your research responses are anonymous. If you choose to leave an email for follow-up, it is stored separately and is not linked to your answers.

● Spoken answers are transcribed, then the voice audio is discarded.

● Responses will be analyzed using AI and human review. Research data will be discarded after the study is complete.

● I plan to share what I learn openly in this newsletter.

Take the Survey!

One more ask

If two or three people come to mind who see this work from a different angle, please send them the survey.

A program leader, executive director, evaluator, development lead, foundation colleague, consultant, board member, or the person who somehow became responsible for the data may each see a different part of the problem. That range will make the findings much more useful.

Thank you for lending me 10 minutes of your experience. I will report back on what I learn.

research.anthralytic.com

Anthralytic is an Impact Intelligence platform for mission-driven organizations. Learn more at anthralytic.com.

“What if we just don’t?”

Nobody jumped on it. There was a pause I’d describe as relieved. And it is a clean position, that one. No vendor review. No training line item. No uncomfortable conversation eighteen months from now about the thing the tool got wrong and who signed off on it. It sounds like caution, and in our sector caution reads as integrity.

I didn’t argue. I’ve been in enough of these meetings to recognize the moment when arguing costs you the room.

But I’ve been chewing on it , and on my lip, ever since, which is why I had to write this.

First, the part where I agree

I’ve spent a lot of this newsletter making the case against.

The energy and water these systems pull, and the fact that the people who host the data centers are rarely the people who benefit from them. Training data nobody was asked about. Bias coming back out of the machine wearing a lab coat. The whole shape of the thing, which looks an awful lot like patterns our field should recognize by now, and which I’ve been rude about in print.

None of that gets filed away because I’m about to argue the other direction. I’m not asking anybody to soften the critique.

I’m asking a narrower question, which is what the critique actually buys an organization once it gets converted into a policy that says no.

Because I think two different things have gotten fused together in our heads. Refusing to use a technology. And refusing to be affected by one.

Saying no doesn’t turn it off

A no-AI policy does not give you an organization without AI. I have never once watched it do that.

What it gives you is an organization where the AI use goes quiet.

Your staff are already using it. Not the reckless ones. The conscientious ones. The program manager with four deadlines and no research assistant, at 9:40 on a Tuesday night, on her own phone, on her own account, pasting in whatever she needs help with. The policy did not stop her. It made sure she can’t ask anyone for help doing it more carefully, and that she’ll never mention the time she pasted in something she shouldn’t have.

Then there’s everything you bought. It showed up in the grants portal, the case management system, the scheduling tool, the applicant screener. It arrived in a release note. Four bullets, and the third one was the AI. Nobody asked the board. And I’d guess a fair number of the organizations with the strongest positions on this have three or four vendors running client records through an AI model right now, often somebody else’s model on somebody else’s servers, because a checkbox got flipped on by default and nobody was told.

The question to ask your vendors, if you ask them nothing else: which of your features call an AI model, whose model is it, and where does our data go when they do? Most of them can answer. Almost nobody asks.

And your funders are using it. So is the person reading your proposal, and the agency scoring your application, and the consultant benchmarking your outcomes against your peers. Decisions about your organization are being made with these tools whether or not anyone on your staff ever opens one.

So the “no” isn’t buying you abstention. It’s buying a fairly expensive kind of not-knowing about what’s already happening in the building.

I’ve argued for refusing things before

Here’s the part that’s hard to say to people I mostly agree with. Your organization declining to use AI does not shrink a data center. These harms are structural. They move when procurement standards move, when disclosure gets mandated, when enough institutional buyers act together. They do not move because one nonprofit in Minneapolis decided not to use a chatbot. I wish they did. That would be a much easier world to organize in.

Which puts me in an awkward position, because if you’ve read this newsletter for any length of time you know I’m the last person who should be lecturing anybody about refusal.

I’ve walked away from a contract and written about why. I’ve argued that the most important thing an evaluator can do is sometimes know when to stay away, that when your presence is what creates the risk, absence is the intervention. I’ve written that rest is resistance, that exhaustion-as-currency is a colonial inheritance we can decline. I’ve told people to retire indicators, to stop measuring things, to say no to funders.

So I owe an honest account of why this refusal is different from those ones. I’ve been turning it over for a couple of weeks and I think it comes down to a single question.

Does your refusal withhold something the system actually needs?

Walking away from that contract worked because they wanted me. My participation was an input, and taking it back cost them something and cost me something, and that cost is precisely what made it a moral act instead of a preference.

Staying away from a community’s organizing worked because my presence was the risk. The documentation was the exposure. Absence reduced harm directly, immediately, in a way I could name.

Refusing the grind works because the grind runs on our consent. Withdrawing the consent is the whole mechanism.

Now run it on this one. What does a mid-sized nonprofit’s refusal withhold? Not compute. Nobody needed your queries. Not legitimacy, because this industry is not sitting around waiting for the social sector’s blessing. Not your data, which they either already have or never wanted.

Refusal is a precision instrument for situations where you are a necessary input. This isn’t one of those. And the single thing the refusal does successfully withhold is your judgment, from the rooms where the norms in your own field are getting set. Somebody is going to write the rules for how this gets used in evaluation, in service delivery, in grantmaking, and every ethical opt-out is one fewer ethical objection in that document.

Which is a strange outcome for a principled act. We kept back the one thing anybody could have used.

The gap won’t sort us by how careful we were

The other reason I can’t get comfortable: opting out doesn’t stop it for anybody else. It just picks which side of a widening gap you stand on, and I don’t think that gap is going to sort people by how thoughtful they were.

It’ll sort by capacity. Who can answer a question in an afternoon that used to eat three weeks. Who can read all of their qualitative data instead of a sample and a prayer. Who can turn around the thing the funder needs inside the window the funder gave.

And the organizations most likely to opt out are the small, community-rooted, chronically under-resourced ones. The ones whose caution is completely rational, because they have the least room for a public mistake. The ones with the most to gain from the work getting cheaper.

I wrote a while back about how much of our sector’s risk tolerance gets set by whoever happens to be in the room, and about the cost that never lands on anyone’s ledger — the decision made without evidence that existed the entire time. Same ledger here. On one side, harms we can picture: the bad output, the exposed record, the automated judgment nobody caught. Real. Worth being afraid of. On the other side, the analysis that didn’t happen, the program that didn’t improve, the community that went on being underserved because the organization serving it fell three years behind everybody else.

Nobody writes that one up. There’s no incident report for a slow decline.

You can’t govern a tool you’ve never watched fail

But the argument I actually care about is the safety one, and it’s why I keep showing up to these meetings in addition to writing think pieces about them. Which is, yes, what this is.

Last year I gave a model a set of interview transcripts I’d collected myself, from a project I knew cold, and asked for a summary. What came back was clean, well organized, and had quietly dropped the one participant who disagreed with everyone else.

That participant was the finding.

I caught it because I’d done the interviews. Somebody who hadn’t would have shipped it. And that is not a fact you can learn from a webinar. You learn it by using the thing on work you know well enough to check, and getting burned in a way you didn’t predict, and developing the small twitch that says look at that part again before you can explain why.

Governance from below needs people below with their hands on it. Otherwise our AI policies end up like most policies: written by people describing a system they’ve never operated, in language that sounds responsible and prevents nothing. I’ve written that language. I can recognize it now mainly because I’ve watched what it fails to stop.

Fluency isn’t a prize you get after you’ve settled the ethics. It’s the equipment you need to have the argument at all.

What I’d actually put in the policy

Not enthusiasm. A document that says yes with conditions and means both halves of that. Name the data that never goes in. Name the decisions a model never makes about a human being. Eligibility, termination, who gets the slot. Sort your uses into the ones that are fine unsupervised, the ones that need a second set of eyes, and the ones that need a conversation before anybody starts. Require people to say when they used it, so the use becomes visible instead of covert. Put somebody’s actual name next to each system. Put a review date on the whole thing, because anything any of us writes about this in August will be partly wrong by spring.

And keep the skeptics inside. Give the person with the sharpest objections a seat and a login, not an exemption. An objection from somebody who uses the tool every week is worth about ten from somebody who won’t touch it.

That’s a harder document to write than simply “no.” It’s also the only one that describes something true about your organization.

But know why the line is where it is

Those red lines are where I’d start. I want to be careful about them anyway, because “no model decides about a person” can be a principle or it can be a flinch, and from the outside the two look identical.

Here’s the uncomfortable part. The evidence on whether these systems are more or less biased than we are does not line up neatly behind either camp.

A 2024 audit out of the University of Washington ran more than three million résumé comparisons through three models and found they favored white-associated names 85 percent of the time, against 9 percent for Black-associated names. Black male names never once ranked above white male names. Damning, and roughly what most of us would predict.

Then a separate audit put 801 real applications for K–12 teaching jobs through eleven models and found modest disparities running the other direction, slightly favoring women and non-white candidates, at a magnitude the authors placed inside the normal range for human recruiters.

Both are careful studies. They disagree because they tested different models on different tasks with different prompts and measured different things. Which is itself the finding. Is AI biased is not a question that has an answer. Is this model, on this task, compared to what we are doing right now is a question that has an answer, and it’s one you can go get.

That last part is what I think our field should sit with. You can run three million comparisons through a model. You cannot run three million comparisons through your hiring committee. Human bias in these decisions is real, thoroughly documented, and not able to be audited at the moment it actually happens. Model bias is real and auditable. For people whose whole job is working out whether something does what it claims, that asymmetry ought to be interesting rather than beside the point.

The counterfactual is never a fair process. It’s the process you’re running today.

None of which means hand over the eligibility decisions. The failure mode on this side is real and it’s about consistency. A person’s bias is erratic and lands unevenly. A model’s is uniform and lands on everybody. One bad rule ten thousand times is a different animal than a hundred bad Tuesdays.

So keep the red lines. Just hold them as things you’d be willing to test rather than things you already know. We ask programs for evidence that they work all the time. We ought to be able to produce some for our own caution.

(This is roughly the structure I’ve been building a workshop around — the decide, implement, verify move, run against the ways these systems actually break rather than the ways we imagine they might. More on that when I have a date to give you.)

I’m not a neutral party

Obvious thing worth saying out loud: I’m fluent, and I make part of my living in a world that values fluency. When I tell you the only way through is practice, I’m arguing for the value of a skill I happen to have. That should cost my argument something with you. It costs it something with me.

I also know exactly how this reasoning goes bad. “We have to learn by doing” is about one bad quarter from becoming a permission slip for whatever somebody already wanted to do. The learning frame is only honest if it comes with a condition under which you’d stop.

So here’s mine, plainly enough that you can hold me to it. If the community conversation starts getting replaced by the summary of the community conversation. If the analyst’s judgment gets replaced by the analyst’s prompt. If we find ourselves believing outputs we can no longer independently check. That’s not learning anymore. That’s automating, and calling it learning because it’s cheaper.

I don’t know precisely where that line sits. That’s most of why I’d rather be standing close enough to see it.

The only possible opt-out

The choice was never AI or no AI. That one expired, most of us weren’t consulted about it, and there is real grief in that which I don’t want to talk anyone out of.

The choice in front of us is between AI you can see and AI you can’t. Between use you get to shape and use that happens to you.

Say no if that’s the honest answer for where your organization is right now. Some of you have good reasons and I’m not going to pretend otherwise. Just know what the no is buying.

Not an organization without AI. An organization without a say.

Subscribe now

Share

Leave a comment

Anthralytic helps mission-driven, resource-constrained organizations with impact strategy, measurement, and reporting. If you’re writing an AI policy and want something more useful than a prohibition, that’s a conversation I’d like to have.

How I made this: I use AI as a writing tool. The meeting, the argument, the transcript story, and the discomfort are mine. Claude pulled some of my published work for cohesion and I built my argument and we revised and iterated together. The thinking is mine. The typing was shared.

They showed up anyway. They told us things that were hard to say out loud. Someone cried. Someone else stayed late to make sure we understood a point that mattered to her. We took notes, thanked everyone, packed up the easel pads, and left.

The findings went into a report. The report went to the funder. The funder was satisfied.

The community never saw any of it.

Nobody decided that. There was no meeting where we agreed to take people’s stories and not bring them back. It just wasn’t in the workplan, and the workplan is what got done.

I have been part of that ritual more times than I want to count. If you work in evaluation, research, or nonprofit data, so have you.

The Ledger Only Runs One Way

Here is the standard shape of community data in our sector.

A community holds information: experiences, outcomes, stories, numbers. An organization collects it, usually because a funder or a statute requires evidence. The data flows up: from community to organization, from organization to funder, sometimes from funder to a dashboard nobody reads.

Now trace the value flowing back down. The funder gets accountability. The organization gets its next grant. The evaluator gets paid. And what does the community get, exactly? A thank-you? A commitment that their data will be “stored securely on a password-protected server”?

I’ve written that sentence. It answers a question nobody in the community asked. They didn’t want to know whether the server had a password. They wanted to know what we were going to do with what they gave us, and whether they’d ever benefit from having given it.

We have a word for arrangements where value gets pulled out of a community and the returns accrue somewhere else. The word is extraction. We usually reserve it for mining companies. We should be slower to exempt ourselves.

And to be fair, because the fairness is the point, nobody in that chain is a villain. The consent forms get signed. The review boards approve. The data really is de-identified. Everyone is doing their job with reasonable care, under deadline, on a budget with no line item for going back. That’s exactly what should worry us. Extraction doesn’t require bad intentions. It only requires a system whose defaults point one direction, and ours do. The question who governs this data? rarely gets asked, so it gets answered by default. And the default answer is: whoever holds it last.

The Word Is in the Room

Which is why something that happened this week caught my attention.

I was in a data strategy meeting for a state agency that serves families, and I heard a word I didn’t used to hear in government buildings.

Sovereignty.

Nobody flinched. Nobody asked for a definition. It was just in the room, being used, specifically about tribal nations as contributors to the agency’s data. And the questions that followed were not the usual ones about storage and logins. They were: if communities are giving us data, how do we make sure they have not just access to it, but useful access? Why would they want to give us data at all? What is the reciprocity? How will it be used, and does the data sharing agreement say so?

I’m hearing this more lately, and I’m grateful for it. I also want us to know what we’re saying when we say it. Because sovereignty is a word that can transform a data system, or get laminated onto one that works exactly the way it always has.

Sovereignty Is Not a Metaphor

When tribal nations are at the table, sovereignty is not a value statement. It is a political and legal reality. Tribal nations are governments. Data about their citizens is not a resource an agency happens to hold, and the frameworks for exercising authority over it already exist. They were built by Indigenous communities, who are among the most studied and least served peoples in the world.

In Canada, the First Nations Information Governance Centre established the OCAP® principles: Ownership, Control, Access, Possession. Regular readers have met OCAP here before: as a challenge to how AI governance disguises taking as sharing, as a reminder that the knowing belongs to communities, not the evaluators who surface it, and as a framework tested to its limits when documentation itself becomes a risk. I keep coming back to it because of what it refuses to soften. The principles don’t say communities should be consulted about their data. They say communities own it. Control how it’s collected and used. Access it whenever they want. Physically possess it, or decide who does.

Globally, the CARE Principles for Indigenous Data Governance (Collective benefit, Authority to control, Responsibility, Ethics) were built as a deliberate complement to FAIR, the open-data framework that wants data Findable, Accessible, Interoperable, and Reusable. I leaned on CARE when I made the case for AI governance from below. FAIR asks: how do we make data easy to use? CARE asks the question FAIR skips: easy for whom, and to whose benefit?

The challenge underneath these frameworks reaches past their origins, to every community that has ever handed its information to an institution: sovereignty is not a feeling of being respected. It is the actual authority to decide.

Most of what our sector calls data governance is really data custody: rules about storage, security, and permissions among professionals. Governance is about authority. A community can have its data encrypted to military standards and still have no say in anything that matters.

Useful Access

The phrase from that meeting I keep turning over is useful access, because it names a gap our sector loves to paper over.

Access is a portal login. Access is a raw export and a data dictionary written for analysts. Access is technically true and practically worthless, the data-system equivalent of a legal notice printed in six-point font. You can check the box marked “transparency” without transferring an ounce of capability.

Useful access means the data comes back in a form that supports the community’s own decisions, on the community’s own questions. It might be a briefing instead of a table. It might be the analyst’s time, not just the analyst’s output. It might mean the community defines the indicators that matter to them and the system reports on those, not only on what the statute requires.

The test is simple: after access is granted, can the community do something they couldn’t do before? If not, you’ve handed them a key to a locked room with the lights off.

Reciprocity, or: Why Would They Want To?

The other question from that meeting deserves to be printed on the wall of every data office: why do they want to give us data?

Not “how do we get them to.” Why would they want to.

If the honest answer is “nothing in it for them, but we need it,” then what you have is not a data partnership. It’s extraction with paperwork. And it will behave like extraction does: trust erodes, participation drops, the data gets thinner and more grudging every year, and everyone wonders why response rates are falling.

Reciprocity means the arrangement is worth it from both sides of the table. Data flows in; value flows back: analysis they can use, their questions answered, capacity built, decisions influenced. This is where data sharing agreements earn their keep. I wrote recently about moving decisions from personalities to agreements. Same move here, one step further: the agreement shouldn’t just govern security and permitted uses. It should name what the contributing community gets, who has authority to say no, how data comes back, and what happens when the community wants something changed. Communities can be parties to data agreements, not subjects of them.

A data sharing agreement that only describes obligations flowing one way is just the ledger again, notarized.

Four Questions That Find the Truth Fast

Strip away the policy language and governance comes down to four questions. Ask them about any dataset you work with.

Who decided what got collected? If the funder’s indicators drove the instrument, the community’s priorities weren’t governing anything. The community was just being measured against someone else’s theory of their lives.

Who can say no? Not on the consent form at intake. Now. If a community wanted a question retired, a dataset deleted, an analysis stopped, is there a door they could knock on? If there’s no mechanism for no, the yes was decoration.

Where does it live, and who can walk in? Possession sounds like a technicality until you notice that whoever holds the data holds every future decision about it.

Who benefits from its use? Follow the data’s working life. Every report it feeds, every grant it supports, every decision it informs. How many of those land back where the data came from?

I have projects in my own portfolio that fail three of these four. This is not a purity test. It’s a diagnostic, and the first patient is the mirror.

Still Theirs

The focus group from the beginning of this piece is years gone. The easel pads are landfill. The report is in a drawer, or wherever reports go. But somewhere in a system, some of what those people said that night is probably still sitting in a row. Data outlives workplans.

What gives me hope is the distance between that room and the one I sat in this week, a room where the questions got asked at the design stage, while the defaults are still wet cement. That’s the moment. Once a system is built, its assumptions about who decides get very expensive to change.

So if you’re anywhere near a data conversation right now: say the word. Ask the reciprocity question out loud. Put useful access in the requirements, not the appendix.

Because the question was never really whether the data is secure.

The question is whether it’s still theirs.

Anthralytic is where mission-driven, resource-constrained organizations can get guidance with impact strategy, measurement, and reporting. If your data sharing agreements only describe obligations flowing one way, I’d love to help you rewrite them.

State government work. A table full of people who actually wanted to use data to inform decisions. Not performatively. Not because a strategic plan told them to. They had real questions, the data existed, and they wanted answers before the next round of decisions got made.

If you have worked in this field for any length of time, you know how rare that is. Usually the hard part is convincing anyone to look at the data at all.

And yet the work stalled.

Not because the data was bad. Not because the questions were wrong. Not because the money ran out. It stalled because one person, positioned exactly where they could stall it, was intent on stalling it. And everything slowed to the speed of that one person’s comfort.

The Reminder I Keep Getting

Here is something my work keeps teaching me, and I keep having to relearn: data is personality-driven.

We talk about data like it is a system. Pipelines, governance, dashboards, evidence-based decision making. The language is all infrastructure, as if information flows through organizations the way water flows through pipes.

It doesn’t. It flows through people.

Personalities decide what gets used and what sits untouched. Which projects go forward and which ones die in a queue. Which partnerships form, because two people trusted each other, and which ones never start, because two people didn’t. How fast anything moves. Whether anyone gets to try something new.

The dataset never decides anything. A person does. And that person’s fears, enthusiasms, grudges, and hopes are as much a part of your data system as any server.

The Stall Is Not Villainy

Now let me be fair to the person holding the brake, because this part matters.

Their concern was data privacy. And data privacy is not a pretext. It is a real thing, and in government it is a deadly serious thing. Government data is people’s lives. Health records. Case files. Addresses. Kids. A breach is not an abstraction; it is a specific harm to a specific person who never agreed to be in your dashboard.

And this is not speculation. Data does get violated. Records exposed. Identities compromised. Information that people handed over to get help with one thing, used for something else entirely. Anyone who has watched that happen, or cleaned up after it, comes by their caution honestly.

Somebody should be worried about that. Somebody should be the person in the room who asks the uncomfortable questions about who can see what and why. Over the years, in other rooms and other roles, I have sat through enough data-sharing conversations that treated privacy as a box to check that I am glad when someone refuses to check it.

So this is not a story about a villain. The person slowing the work down was doing a job that someone needs to do.

The problem is not the concern. The problem is where the concern lives.

One Hand on the Dial

There is a real balance to be struck between using data and protecting the people in it. That balance is the whole question. Use without protection is extraction. Protection without use is a locked filing cabinet that helps no one.

But in this case, the balance wasn’t being struck by a policy, or an agreement, or a shared framework the whole team had hashed out. It was being held by a single personality. One person’s risk tolerance had quietly become the entire agency’s risk tolerance.

And when one hand holds the dial, the cost lands on everyone.

Here is what that cost looked like this time. There was a decision to be made about early childhood education. A real one, with real money and real kids attached. The data that could have informed it existed, sitting in systems the state already owned. But it wasn’t made available in time, so the decision got made without it. Not badly, necessarily. Just blind. And no one will ever write an incident report about that. Somewhere down the line, kids will feel that choice, and nobody will trace it back to a data request that stalled.

That is the trade-off we don’t talk about. On one side of the ledger, the violated data: the breach, the exposure, the harm we can name and fear. On the other side, the decision made in the dark. Both are real. Both have victims. Only one of them ever makes the news.

Decisions get made without evidence that existed and was sitting right there. Partners drift away, because momentum is a resource and you can only ask people to wait so long. Staff stop asking for data, because asking never goes anywhere, and eventually the not-asking becomes the culture. Innovation dies politely, in meetings, without anyone ever saying no.

Data that never gets used also fails the people it describes.

We Are All the Personality in the Room

It would be comfortable to write this as a story about one difficult person. It would also be dishonest.

Because I have been the personality in the room. My enthusiasm has gotten datasets opened that would otherwise have stayed shut. Relationships I happened to have got partnerships signed that a cold email never would have. And I have to assume the reverse is true too, that somewhere along the way my own hesitations, my own fears, my own limits on a given Tuesday slowed down work that someone else needed.

There is no personality-free version of this work. The fantasy of a neutral, frictionless, purely technical data system, where information moves on merit and decisions follow evidence automatically, is just that. A fantasy. Every data system is a group of people, some of whom trust each other, deciding together what they are willing to know and act on.

Once you see that, you can stop being surprised by it. And you can start working with it.

What to Do With This

I don’t have a framework for you. But I have a few things I am trying to practice.

Stop pretending the blocker is technical. If the work is stalled because of a person, then the work in front of you is relational. Find out what they are actually protecting. Sometimes it is the public. Sometimes it is their own liability. Sometimes it is a bad experience from ten years ago that nobody else in the room knows about. You cannot address the fear until you know which one it is, and no amount of better documentation will do it for you.

Move the balance from a person to an agreement. Data-sharing agreements, tiered access, clear de-identification standards. These are unglamorous documents, and they are also how a group takes the dial out of any one person’s hand. Written rules mean the balance between use and privacy gets struck once, together, on purpose, instead of re-struck in every meeting by whoever showed up with the strongest opinion or the most fear.

Make the cost of non-use visible. Privacy risk gets documented, assessed, and reviewed. Stalled decisions don’t. Start naming both. What did we not learn this quarter? What decision got made on instinct because the evidence was locked up? You do not have to be aggressive about it. You just have to make sure the ledger has two columns.

And invest in the champions while they are there. Personality-driven cuts both ways. When someone across the table wants to use data well, that is not a nice-to-have, that is the whole game. Champions leave, get promoted, burn out. The window when the right person is in the right seat is when the agreements get signed and the precedents get set. Do not wait.

The Person, Not the Pipeline

The work I started with is still moving. Slowly. Person by person, which I suppose is the point.

The next time a data project around you stalls, or takes off, look past the pipeline and find the person. There is always a person. The data was never going to decide.

Anthralytic helps mission-driven, resource-constrained organizations with impact strategy, measurement, and reporting. Most of that work, it turns out, is people work. If your data is stuck somewhere between a person and a pipeline, come say hello.

Leave a comment

Share

This one is about the practice underneath all of it: sitting. Eight hours of zazen over one weekend. The agony and the ecstasy, and I mean both words literally.

What zazen is

Zazen is seated meditation, the heart of Zen practice. You sit upright on a cushion, facing a wall, eyes lowered but open, and you stay there. At Ryumonji we sat in periods of forty minutes, broken by ten minutes of kinhin, slow walking meditation that keeps you in a meditative state while giving your body a break, and then forty minutes more, several rounds a day.

Why do people do this? The honest answer is strange: zazen is goal-less. It isn’t for relaxing, reducing stress, or optimizing anything. The practice is to be present with what is actually happening, which turns out to be one of the hardest things a person can do. Not a trance. Not an escape. The opposite of escape: staying.

From the outside, it barely looks like anything. At one point my mind wandered into imagining a visitor arriving at the monastery, someone who didn’t understand zazen. They would walk the grounds looking for people and find no one. Eventually they would reach the meditation hall and see a room full of humans facing the wall. Completely awake. Eyes open. Noticing everything, moving nothing. Someone would rise quietly to attend to them, but how strange it would seem from the outside. Then I noticed my mind had drifted, and I brought it back to the moment.

In part one I described a pattern: things look easy, become overwhelmingly hard, and become easy again. Sitting corrects that story. It isn’t easy, then hard, then easy, finished. It’s waves. Ease and difficulty keep arriving, all weekend, and as far as I can tell, for a lifetime. The practice isn’t reaching the shore. The practice is the waves.

The body keeps the score

Here is something you may not know if you haven’t meditated for long stretches: it can be intensely, physically painful. Sometimes without any explanation you can find. The body sits still, doing nothing, and begins to burn and throb and shout. Bessel van der Kolk titled his book on trauma The Body Keeps the Score, and long sitting demonstrates the point. Our bodies hold stories, and when everything else goes quiet, they start telling them.

The instruction is not to suppress any of this. It’s to meet it. An itch rises, and instead of scratching on autopilot, you investigate. What does it actually feel like? How deep does it go? What does it bring up, and why? Will it pass without being scratched? The discipline is curiosity without attachment: don’t cling to your first thought about the itch, or your second. This applies to far more than itches.

Pain is where that discipline gets tested, and where mine failed in an instructive way.

I have a history with not moving. When I first started meditating, having to move made me angry at myself. It felt like a failure of control, an imposition on everyone around me. The person on the next cushion is perfectly still. Why can’t I do that? Without noticing, I had turned stillness itself into an attachment.

The weekend found that attachment quickly. During the first two sittings my cushion was firmer than what I use at home, which pushed my posture into an alignment that was wrong for my body. Throbbing pain built in my legs until one of them fell asleep. I stayed completely still through all of it, because I felt I was supposed to. In zazen we practice letting go of attachments, and there I was, attached to being still. In agony, quietly, on principle.

Later that weekend I described all this to one of the priests, and he delivered the most perfectly Zen answer.

“You can move.”

I chuckled. My old attachment to not moving had followed me all the way to Iowa. The point was never immobility. We don’t chase the body’s every whim and itch. But when agony is blocking presence, the answer is one sentence long: shift your posture.

That’s what I love about Zen. It’s so simple. And it isn’t.

The mind makes its bids

The most common misconception about meditation is that the goal is to stop thinking. It isn’t, quite. The practice is to be in the present moment: not in memories, not in plans, not in stories or worries. The monkey mind bids constantly for our attention, and it’s very good at its job. Fighting it isn’t the practice either. You notice you’ve been carried off, you acknowledge it without judgment, and you return to what’s here. With curiosity: how does this feel, in this moment? Then the mind wanders again, and you return again. Waves, once more.

Eight hours of this is not eight hours of serenity. Some sittings passed with my mind wandering the entire forty minutes. During others I mostly wished I hadn’t come. Many were negotiations with numbness, itching, or pain. And some were something else entirely: fully present, in a hall of people with whom I share a lineage and an ethical framework, though our vocations and paths differ completely. Connection and irritation traded places without warning. One sitting I felt joined to everyone and everything; another, I was mostly annoyed at the young college student nearby who would not stop moving.

That student turned out to be the weekend’s quiet teaching. When we finally talked, he reminded me intensely of my son. It was his first time meditating. Ever. He had signed up for a silent retreat with eight hours of sitting out of pure curiosity, probably without knowing what he’d agreed to, and he stayed for all of it. The annoyance dissolved on contact. What he did was incredible. Every cushion in that hall held a story like that, and my irritation had been a story too, one more thing to notice and release.

The ecstasy arrived on the same schedule as everything else: unearned and unplanned. The 5:30 morning sittings, the ones I had dreaded most as someone who needs more sleep than she wants to, became the most meaningful of the weekend. Ninety minutes of stillness while the sun crossed the room, its light moving over the floor slowly enough that only a quiet mind would catch it. On the last morning, the entire sitting filled with overwhelming love and gratitude. Not pride, not accomplishment. Love for everything, and gratitude to be alive and experiencing it alongside these particular people. It came in a wave, like the pain had. I didn’t earn either one.

What does this mean for evaluation?

Zazen is goal-less, and I try to honor that. So consider these not outcomes but things the cushion keeps teaching me that follow me to work.

Sitting has taught me to slow down and to reserve judgment a beat longer than feels natural. To stay present in the meeting, the interview, the dataset. Repetition invites autopilot; the fifteenth site visit and the fortieth survey response blur unless you treat them with the same curiosity as an itch. What comes up for us when we look at the shape of this data? Not only what it says. What it brings up, and why. And beneath every finding, the quietest question I know: how do I know what I think I know?

The waves matter just as much. Evaluation work arrives in waves. Projects feel easy, then impossible, then easy again. Findings we welcome trade places with findings we resist. Seasons of connection to the work alternate with seasons of wishing we hadn’t come. Clarity is not a shore we land on. The practice is noticing where we are in the wave, and returning.

And when the pain is structural, when the cushion itself is wrong for the body, remember the priest. Nobody is obligated to sit in agony on principle. The timeline breaking the team, the method harming the community, the indicator nobody believes in: you can move. Discipline is not attachment to a posture. It’s so simple. And it isn’t.

That’s the end of the series. Four things came home with me from the Dragon Gate: a knot, a chant, a drum, and a cushion. The sesshin ended. None of them have.

Glad to be riding the waves with you.

Anthralytic builds evaluation software for the long practice: tools that help organizations stay present with their data, ride the waves, and notice what comes up.

Share

Leave a comment

The meditation cushion (rightmost) where I spent eight hours over the weekend

Sandalwood, the most glorious I have ever smelled, somehow both clean and wooden at once. It filled the open Buddha hall: high ceilings, wood trim, the altar with the Buddha and the offering. On the floor, about thirty zabutons, the flat square mats used for sitting, each topped with a zafu, the round meditation cushion. Monks, priests, and lay people like me, all on the same floor. The abbot sat above us on the tan, the raised wooden platform, on his own cushion. He wore his regular brown robe, but with a bright orange cloth draped across it that I hadn’t seen before: his okesa. An okesa is the Buddha’s robe, a rectangular patchwork cloth that priests receive at ordination and wear draped over the left shoulder. The everyday ones come in muted browns and blacks. The bright ones come out for ceremony.

And here’s what surprised me. I expected solemnity. What I found was smiling. The whole room hummed with eager anticipation, but the mood wasn’t heavy. It felt like the minutes before something joyful. Something about it reminded me of stakeholder meetings I’ve sat in at agricultural cooperatives, or scorecard workshops where a community gathers around its own data: everyone with a role, formality in service of belonging, the sense that whatever happens next belongs to the whole room.

This is part three of a four-part series about what I learned from the Dragon Gate. Part one was about oryoki and the knot. Part two was about chanting the lineage. This one is about a ceremony I was lucky enough to witness, and a koan I am still carrying.

Six months with one story

In a Zen practice period, one student serves as shuso, the head student for that season of training. It is a role, not a rank. The role passes to someone new each practice period, and serving as shuso is a rite of passage on the priest’s path, which means the room that day almost certainly held people who had once sat in that seat themselves, and some who will in the future. Among everything else that role asks, the shuso spends the practice period living with a single koan: one of the short, strange teaching stories that Zen students contemplate, often a recorded exchange between an old master and a monk. Not a semester’s reading list. One story, carried for six months, through every sitting, every meal, every work period.

At the end comes the ceremony, called hossenshiki, sometimes translated as dharma inquiry or dharma combat. The shuso receives the shippei from the abbot, a curved bamboo staff ordinarily reserved for a teacher who has been authorized to teach. For this ceremony, the teacher’s staff is in the student’s hands. He takes his seat. He reads the koan aloud. Another priest reads the accompanying verse. And then the room gets to ask him about it. Anyone. Question after question, in a formal call and response that has its own choreography, the way everything at the monastery does.

This is the koan our shuso carried, Case 44 of the Blue Cliff Record, a collection of one hundred koans compiled in China nine hundred years ago:

Ho Shan imparted some words saying, “Cultivating study is called ‘learning.’ Cutting off study is called ‘nearness.’ Going beyond these two is to be considered real going beyond.”

A monk came forward and asked, “What is ‘real going beyond’?” Shan said, “Knowing how to beat the drum.”

Again he asked, “What is the real truth?” Shan said, “Knowing how to beat the drum.”

Again he asked, “’Mind is Buddha,’ I’m not asking about this. What is not mind and not Buddha?” Shan said, “Knowing how to beat the drum.”

Again he asked, “When a transcendent man comes, how do you receive him?” Shan said, “Knowing how to beat the drum.”

I’m not going to explain it

That’s not me being coy. A koan is not a riddle with an answer key, and explaining one is a good way to kill it. The point is that you sit with it until it opens for you, and what it opens into is yours.

So I’ll only tell you what happened to me. I had almost no time with the koan before the ceremony, and I understood, honestly, nothing. Four questions, one answer, four times. That was as far as I got.

The first question came swiftly. I can’t remember exactly what it was. But the shuso’s answer was “knowing how to beat the drum.” Smiles all around the room. What you might not expect is that Zen priests have a sense of humor.

Then for the next half hour I watched the shuso answer for it. People asked about the history: who Ho Shan was, where the teaching came from. People asked intellectual questions about the meaning. And people asked about their own quotidian lives: work, family, the ordinary Tuesday afternoons of being a person. He met all of it. And somewhere in the middle of the questions, I understood more than I had. Not everything. More.

Now I want to do the slower thing. I want to really sit with it, and find out what it means for me. That part hasn’t happened yet, and I’m not going to rush it.

The examination that ends in blessing

Here’s the part of the ceremony I can’t stop thinking about as an evaluator.

The questioning was real. The shuso had to actually answer, in front of everyone, with no notes and no advance list of questions. The community was allowed to press him. And the whole time, the room was warm. People smiled. The form held everyone.

When the abbot was satisfied that the shuso had answered enough to show he understood, he told him that he had done well, and that he was fit to be a teacher. And then, one by one, the whole room congratulated him. It was one of the most emotional things I have ever been part of.

Sit with that structure for a second. It is an examination. It is rigorous, public, and unscripted. And its purpose, from the first stick of incense, is to confirm someone’s readiness and celebrate it. The accountability and the love are the same gesture.

Evaluation almost never feels like that, and I keep asking myself why not.

What the ceremony asks of evaluators

Two questions followed me home.

First: what would it mean to sit with one question for six months? Evaluation runs on a different clock. An RFP cycle, a data pull, a 30-day analysis window, findings due before the program has even stopped changing. We answer questions at the speed of contracts. The shuso lived with his question through six months of sittings and meals and chores, and when the ceremony came, the answers were in him, not in his notes. I think about the difference between analyzing a question and living with one. Most evaluations I’ve been part of did the first. The ones I’m proudest of got somewhere near the second.

Second: what would it mean to answer for our findings in the open? Not a briefing deck delivered upward to the funder, but a room where anyone can ask: the program staff, the community the data came from, the person whose life sits inside the percentages. History questions, method questions, and quotidian ones. When we serve findings only to the people who paid for them, we get to skip the hardest and most honest questions. The shuso didn’t get to skip anything. And because the room was rooting for him, he didn’t need to.

That’s the piece I want to steal: rigor whose endpoint is capacity, not verdict. An examination that ends with the community saying, one by one, we trust you to carry this now.

Still carrying it

I don’t have a tidy ending, because the koan isn’t done with me. That’s the honest state of things, and it feels right for a series about practice.

The verse that accompanies Case 44 ends with a warning I’ll leave here without comment:

Don’t be careless! The sweet is sweet, the bitter is bitter.

Sit with it. See what it does.

Part four is the last one: sitting practice itself, eight hours on a cushion over a weekend, and everything that comes up in waves when you finally stop moving.

Glad to be sitting with the question alongside you.

Anthralytic builds evaluation tools for communities that want to gather around their own data and answer for it together.

Leave a comment

Share

Name after name, out loud, together. Beginning with Shakyamuni Buddha, then down through India, into China, across to Japan, and forward to Dainin Katagiri Roshi, whose dharma heir founded the monastery where we sat. Generations of them. Some of the names belong to people who died twelve centuries ago, and there I was, a lay practitioner from a small Midwestern sangha, saying them with my own voice.

Every name in the line was somebody’s teacher. Every name was first somebody’s student.

The bowls taught me about the meal. The chant taught me about time.

This is part two of a four-part series about what I learned from the Dragon Gate. Part one was about oryoki, the formal meal, and the knot I struggled with. This one is about the names.

Nobody wakes up alone

In modern Western culture, when we say lineage we usually mean blood. Family trees, ancestry charts, the DNA kit that tells you where your great-grandparents came from. That kind of lineage matters. It shapes who we are and what we inherit, chosen or not. But that’s not what this post is about. This post is about lineages of teaching, of craft, of practice. Not the lines you are born into, but the lines you are received into.

That is the line we chanted at Ryumonji. In Zen, the lineage chant is a record of dharma transmission: the teaching passed from teacher to student, face to face, in an unbroken line. Warm hand to warm hand, as the tradition says.

Historians will tell you parts of the early record are legend, and that’s fine, because accuracy isn’t really the claim. The claim is relationship. Nobody woke up alone. Every person in that line received the teaching from someone and handed it to someone else. When you chant the names, you’re not reciting a family tree. You’re acknowledging that what you have was given to you.

And here is the detail I keep returning to: everyone in the hall chants it. The abbot chants it. The monks chant it. The lay people chant it. The person who fought her oryoki knot at breakfast that same morning chants it. The lineage doesn’t belong to the credentialed few. It belongs to everyone in the room, because everyone in the room is downstream of it.

Evaluators have a lineage too

We just never chant it.

Imagine it for a moment. Tyler, who asked whether programs actually did what they promised. Campbell, who dreamed of an experimenting society. Scriven, who insisted that evaluation means judging merit and worth, and made us stop pretending otherwise. Weiss, who showed that findings take on lives of their own. Patton, who asked who would actually use any of this. Mertens, who demanded we center the people research had marginalized. Chilisa, Cram, Bowman, who showed that communities own their knowing and always have.

Each one building on the one before. Each one arguing with the one before. That’s what a lineage is. It isn’t agreement. It’s inheritance.

The evaluation field usually draws this as a theory tree, with branches for methods and use and valuing. I love the tree. But a tree maps positions. A lineage does something different: it says you received this. When you run a focus group or build a logic model or fight for a participatory process, you’re not just using a technique. Someone handed it to you. Someone handed it to them. And each handoff came with adaptations and additions, deletions and changes. Nothing in the line arrives untouched. That’s not corruption of the lineage; that’s how a lineage stays alive.

I met my ancestors in a graduate seminar

Here’s my confession: I only formally met this lineage last year, in a grad school class that walked through the theorists one by one.

By then I had been doing evaluation for years. Almost everything I know, I learned by doing: by writing the report, getting it wrong, sitting in the meetings, watching what actually helped and what just performed helpfulness. I didn’t have a singular teacher the way the monks at Ryumonji have theirs. There was no ceremony, no transmission, no unbroken chain of hands to mine.

And I don’t think I’m unusual. That’s how most evaluators come up. The lineage exists, but the field keeps it behind a credential, in graduate seminars many working evaluators will never sit in. At Ryumonji, nobody checked my qualifications before handing me the names. In evaluation, you can practice for a decade before anyone shows you whose shoulders you’ve been standing on.

But I realized when I returned from Ryumonji that I do have a lineage, but it isn’t a chain of personal teachers. It’s chosen. There are evaluators going back generations whom I subscribe to, each building on the others, and I took refuge in them through their books and their frameworks and their arguments. You adopt your ancestors in this field. And the learning-by-doing part has its own Zen echo, because nobody transmitted oryoki to me either. My hands learned the knot through repetition. The practice itself was the teacher.

So who’s in your line? Not who should be. Who actually is. It’s worth writing the names down. If you’re an evaluator, I invite you to try this exercise: write down your evaluation lineage, the people whose thinking your practice is built on, however you met them. And if you’re not an evaluator, whatever your vocation is, write yours. Teaching, nursing, coding, organizing, parenting. Every craft has a line behind it. See whose names surface.

The two chants

Now the harder part.

For most of Zen’s history, the lineage chant contained only men. The women were there the whole time, teaching, practicing, transmitting, but the formal records erased them. Grace Schireson, in her book Zen Women, describes the women’s line as a stream gone underground, surfacing again and again in different places, never granted a continuous record.

Then, in 2010, American Soto Zen did something remarkable. The Soto Zen Buddhist Association adopted a Women Ancestors Document: a recovered lineage beginning with Mahapajapati, the Buddha’s aunt and stepmother and the first woman ordained, running through the Indian, Chinese, and Japanese women the records had left out. Many centers now chant both lines. Fourteen centuries underground, and then a community sat down, wrote the names back in, and started saying them out loud.

Recovering a lineage is a choice. It is an act of repair.

Here is my second confession: I don’t know whether the women’s names were chanted at Ryumonji. I don’t have the chant book, and I can’t reconstruct it from memory. I can still hear the traditional line. I cannot tell you whether the recovered one was in the room.

That’s how absence works. It doesn’t announce itself. You have to already know the missing names to notice they’re missing.

Evaluation has its underground stream too. The community members whose insight became “findings” with no name attached. The local staff who collected the data and never appeared in the report. The practitioners whose methods were absorbed into the field without credit. We have one list we keep and one list waiting to be recovered, and most of us, most of the time, can’t say who’s on the second list. Not because we checked and found it empty. Because we never learned to notice.

So the question the two chants left me with: which list are we keeping? And who is waiting on the one we’d have to choose to write?

Saying the names out loud

I don’t have a ceremony to offer. But there are small ways to chant.

Name the people whose work yours builds on, and not just the famous ones. Put the local data collectors in the acknowledgments. Cite the community report, not just the journal article. Tell the new evaluator on your team where the method they’re learning came from, and who fought for it. And maybe stop keeping the lineage behind the paywall of a degree, because the names belong to everyone doing the work.

One more thing from the sesshin, for next time. I got to witness a ceremony in which the monastery’s head student answered questions from the whole community about a single koan he had spent six months living with. That koan begins with these words: “Cultivating study is called learning. Cutting off study is called nearness. Going beyond these two is to be considered real going beyond.”

All this study. All these names. And the teaching points past both. That’s where we’re going in part three.

The line doesn’t stop with us. Someone will chant our names, or won’t.

Glad to be standing in lineage with you.

Anthralytic is my way of passing the work along: evaluation software handed to resource-constrained organizations with fewer gates on it.

Share

Leave a comment

The hall was a mix. Some people had decades of practice behind them: one smooth pull and the cloth fell away, bowls nested inside like the whole thing had been waiting to open. Others, like me, were new to oryoki. I’d done it exactly once before. So while the veterans unwrapped their sets in one unhurried motion, the rest of us quietly fought our napkins, stealing glances down the row to see what came next.

I returned Sunday from a sesshin at Ryumonji Zen Monastery, the Dragon Gate Temple, tucked into the driftless hills of northeast Iowa. I went with my sangha, the community from my local Zen Center. And I’ve been thinking about that knot ever since.

This is the first post in a four-part series about what I learned from the Dragon Gate, four things I carried home that keep speaking to my work as an evaluator: the oryoki lesson, lineage, the shuso ceremony, and sitting practice itself. We start with the meal. Food. The nourishment that makes everything else possible.

What a sesshin is

Sesshin means something like “gathering the mind.” It’s an intensive silent retreat, days built around zazen, sitting meditation, in a steady rhythm: forty minutes of sitting, ten minutes of kinhin (walking meditation), then forty minutes more, several rounds a day, woven between work practice, services, and formal meals. Over the weekend it added up to about eight hours of zazen. Eight hours of doing, by any productive measure, absolutely nothing.

Ryumonji was founded by Rev. Shoken Winecoff, a dharma heir of Dainin Katagiri Roshi, one of the Japanese teachers who brought Soto Zen to America and the founding abbot of the Minnesota Zen Meditation Center. The monastery runs on forms that have been handed down for centuries. Wake to the bell. Sit. Walk. Sit. Eat. Work. Sit.

Here’s what I keep relearning: practices like zazen and oryoki don’t stay on the cushion. They train me to be mindful in every other corner of my life, including my work. By day I’m the data governance lead at the Department of Children, Youth and Families, working with early childhood data. In the evenings I’m building Anthralytic, software to make social impact work accessible to resource-constrained organizations. I spend my weeks thinking about how information moves between systems, who touches it, and what care it deserves. It turns out a monastery meal has a lot to say about that.

What oryoki is

Oryoki means, roughly, “just the right amount.” It’s the formal meal practice of Zen monasteries: a set of nested bowls wrapped in a cloth, with utensils and napkin folded inside in a precise way. Meals are taken in silence, in the meditation hall, with chanting, in unison, according to a choreography that covers everything: how the bowls are opened, the order food is served in, how you signal enough, how the bowls are cleaned, and how the whole set is folded and tied back into that knot.

The cleaning deserves its own moment. At the end of the meal, hot water is poured into your bowl. You wash the bowl, and then you drink the water. This sounds strange until you understand why: nothing is wasted. The meal ends the way it began, with just the right amount. Every grain, every trace, is received rather than thrown away. The last of the water is collected and offered to the hungry spirits, so that even what you don’t take in becomes a gift.

It is, on paper, just eating.

What I love about it is that it makes the connections visible. Sitting there with my bowls, I thought about everything that arrived with the food: the fields it grew in, the hands that harvested it, the cooks in the kitchen who woke before the rest of us, the recipes honed over decades of monastery practice, the people eating beside me in the hall, the meaning carried in the bowls themselves. The meal chants say this out loud. Before eating, we chant the Five Contemplations, which begin:

We reflect on the effort that brought us this food and consider how it comes to us.

Nothing in the bowl is separate from anything else. The chants reach backward to the ancestors and the labor that brought the meal, hold the present company in the hall, and then dedicate the meal forward to all beings. Past, present, future, all at one meal.

If you’ve read my work on evaluation from a Buddhist lens, you’ll recognize this as interbeing. But sitting in the meal hall, it isn’t a concept. It’s breakfast.

The transfer bowl

Here’s where my evaluator brain woke up.

The first bowl, the largest one, is the Buddha bowl. When the servers come down the row, the grain is received there first, and then you transfer it into the second bowl before you take it in.

That’s data work. That’s exactly data work.

Data almost never arrives ready. It comes to us in whatever vessel it was collected in: an intake form, an administrative system, a survey built for someone else’s question. Before anyone can actually take it in, it has to be transferred, carefully, into another bowl. Cleaned, restructured, matched, made usable. In my governance work, most of what I do is tend that transfer from a relational lens. The care you bring to the pouring, not spilling, not mixing bowls, honoring what the first vessel held, is the whole practice. The bowl the data arrives in deserves respect, because people filled it. Their lives are in that bowl.

Everyone waits

The other thing oryoki taught me: no one eats until everyone is served.

The servers move down the rows, you receive your food, and then you sit with your full bowls and wait. When seconds come around, everyone stops eating, mid-bite if necessary, and waits again until every person has been served. Then the meal resumes, together.

It’s a beautiful acknowledgment of each other. The meal is not mine; it’s ours. And it made me think about how rarely evaluation works this way. We serve findings to the funder first and everyone else eats later, if at all. The community that filled the bowls is often the last to be served, or never served. What would it mean to build evaluation where nobody eats until everyone is served, where the pacing itself says we are doing this together? In my Buddhist evaluation work I’ve argued that the knowing is distributed, so participation isn’t a courtesy, it’s an epistemological requirement. Oryoki builds that requirement into the rhythm of the meal. You cannot rush ahead alone. The form won’t let you.

Easy, then hard, then easy

And then there’s the knot.

I’ve noticed this pattern in almost everything worth learning. At first glance, oryoki looks simple. It’s eating, and you’ve been eating your whole life. Then you actually try it, and it’s overwhelming: the fold of the cloth, the order of the bowls, which chant comes when, how to clean, how to re-tie the set so it’s ready for the next meal. You are certain you will never get it. And then, with repetition, it becomes simple again. A different simple, one that has the whole choreography inside it.

Evaluation is the same shape. From the outside it looks like common sense: did the program work? Then you get inside and it’s all knots: designs, frameworks, stakeholders, data transfers, competing definitions of “work.” Stay with it long enough, through enough repetitions, and it becomes simple again. Not because the complexity went away, but because your hands learned it. Mountains become mountains again.

By the last meal of sesshin, the knot fell open. I hadn’t gotten smarter. I had just practiced.

What’s coming

That’s the oryoki lesson, one of four. In the coming weeks I want to sit with the other three. Lineage: we chanted ours at Ryumonji, every name in the line, and it has me thinking about our lineage as evaluators, all the people whose work we build on whether we name them or not. The shuso ceremony: I got to witness the head student, who had spent six months living with a single koan, stand and answer questions about it from the whole community. Six months with one story. What would it mean to sit with our questions that long? And sitting practice itself: eight hours on a cushion, and everything that comes up in waves when you finally stop moving.

For now, I’m back at my desk, untying knots of a different kind. But I’m trying to bring the meal hall with me: receive what arrives with gratitude, pour the transfer carefully, and don’t start eating until everyone is served.

Glad you’re here at the table.

Anthralytic builds software that makes social impact work accessible to organizations without data teams or big budgets.

The pattern is worth saying out loud, because it is not really about me.

What I built and what happened

The app lays out a set of principles for how AI initiatives in social impact organizations fail, alongside the breaking patterns that show up when those principles are skipped. It is a small educational tool. Each card has a “Suggest Actions” button that calls an AI provider’s API to generate concrete steps an organization could take.

To make those buttons work, the page needed an API key. The right way to handle a key is to keep it on a server, behind a function the browser can talk to, so the key never goes anywhere near the user’s computer. I put the key directly into the HTML, where anyone who opened the page and looked at the source could read it. I’m still learning all of these things.

Eight months later, two notifications arrived in close succession. The first was a billing alert for about thirty dollars in unexpected API charges. The second was a suspension email citing “abusive activity consistent with hijacked resources” and language about the key being harvested from a public source.

Bots crawl the open web for credential strings constantly. Mine was one of millions they found that week.

The cleanup

I revoked the key. I rewrote the demo to call the API from a server-side function. I audited every other project I had built for the same mistake and found that I had reused the same key in several places, which meant the single leak compromised everything it touched. I scrubbed git histories. I treated each small project as a small disaster site, which is what each of them was.

The bill stopped at about thirty dollars. The reason it stopped there is honestly not that I caught it. The provider’s automated abuse detection caught it. The project was attached to a small billing footprint, which kept the blast radius low. Both of those facts belong to the vendor’s infrastructure, not to mine.

That is the part of the story I want to sit with.

The pattern, named by the app it broke

The app I built names four principles that were violated to build it. Build Internal Literacy. Plan for Adversaries. Govern and Minimize Data. Monitor and Recalibrate. Each one fits the story exactly. I do not raise this to be clever about it. I raise it because the pattern is structural rather than personal.

Most of the AI tools small mission-driven organizations are experimenting with right now are built the way mine was. They are built quickly, often by people who are not specialists, in environments where “I will get to it later” is the default operating posture, because the alternative is not building anything at all.

The literacy gap that allowed me to embed an API key in a deployed page is the same gap that allows a small nonprofit to leak donor data through a misconfigured spreadsheet, run a model on biased inputs without noticing, or ship an automation that quietly mishandles edge cases for months before anyone notices. The technical specifics differ. The structural mismatch is identical.

The mismatch is between the speed at which an idea can be tested and the speed at which a tested idea becomes a system that handles real stakes. Demo-grade decisions get made on demo-grade timelines, and then the demo gets deployed and forgotten, and “demo” turns into “production” by accident. There is no moment where someone declares the change of state. The change of state is what the absence of that moment looks like.

What protected me was not me

This is the part that should make any small organization building with AI uncomfortable.

The infrastructure that kept this failure cheap was not infrastructure I designed. It belonged to the vendor. Their abuse detection ran on their schedule, not on mine. The thresholds that triggered the suspension were thresholds they set without asking me. The rate of spend that pushed the system into protective mode was small only because my account happened to be small.

For an organization running on a larger billing footprint, or with a vendor whose detection runs slower, or with a key attached to a higher-traffic project, the same mistake is a much bigger story. The factors that made my version of this story end at thirty dollars are not transferable. They are circumstantial.

Most of what protects small social impact organizations from the worst versions of their AI experiments right now is circumstantial. What stands between a misconfigured demo and a serious incident is mostly the goodwill of automated systems we did not build and do not control.

We do not have the literacy to design the protection ourselves. We do not have the leverage to demand it from vendors. We need to build them both. Myself included.

Leave a comment

Share

Anthralytic helps mission-driven organizations clarify and amplify their impact. We work at the intersection of evaluation, AI governance, and the systems that shape both.

Everyone loves to hate on AI right now.

Here’s a headline from a piece that ran in a Substack weekender yesterday: “My uncle used Claude to write my Nana’s obituary.” The writer is furious, and the headline is meant to make the reader gasp.

There’s a question about AI that almost nobody is asking right now. It’s not whether. It’s how.

Did he just sit with it and talk through what he remembered? Parse through a complicated relationship, find the words for what he couldn’t say out loud? Did he land on the detail that was true: standing at the window, waving, until the car was gone? Or did he type “write an obituary for my grandmother” and submit whatever came back?

Those are not the same thing. “Used AI” covers both. That’s the problem.

The how question is one I see very few people asking. The concerns are loud right now: job displacement, data centers, cognitive offloading, an internet drowning in slop. Those are real. But none of them tell you anything about what the uncle actually did, or whether the obituary was any good. How someone uses a tool is a different question than whether the tool should exist, and we keep flattening them into one.

How matters everywhere, not just in obituaries

My kids’ schools have unclear AI policies or none at all. Teachers tell students not to use AI, then later use AI in the classroom, with no explanation of what distinguishes one from the other. Don’t use it for the essay. Do use it for the research. Why? What’s the principle? Nobody says, because if there’s a policy at all, it was written without one. The students learn that AI is alternately forbidden and assigned, and that adults don’t know the difference. I’ve written before about doing this with my own teenager, working through a paper at the kitchen table while my laptop sat open to Claude. I haven’t fully resolved the contradiction either, and I’ve also questioned who should be doing the teaching when the schools won’t.

The same incoherence shows up in hiring. Many of the job applications I submitted this year, even tech jobs, came with a variation of the same instruction. We want your words to be your own. Do not use AI in this application. Jobs, fellowships, grants. The instruction was everywhere. I used AI on all of them. I sent more than 400 applications over a year and a half. Asking a candidate to do that volume of work without the tools at their disposal is not a measure of authenticity. It’s a measure of who has time. And it’s asking applicants not to use a productivity tool they would almost certainly be asked to use on the job.

The instruction is trying to screen for something real: the difference between someone who did the thinking and someone who didn’t. That’s a legitimate thing to want to know. But you don’t get there by asking the candidate not to use AI and ticking a box to confirm they didn’t. That approach is lazy. Ironically, it is cognitive offloading by the people doing the screening, letting a checkbox do the thinking for them. It is also ineffective, because of course people will use the tools available to them.

Better to judge the output first, and then ask how.

What the how actually looks like

Here’s how I often use AI, since I’m asking you to judge me by the output. I use it in this newsletter. It isn’t a simple prompt like “write me a piece on X.” I use it first as a conversation partner when I have a half-formed idea, and the back-and-forth becomes a process of discovery that helps me understand the situation better. I’ll talk an argument through, push back when the response is sycophantic or imprecise, and come out the other end with a cleaner and truer version of the thing I was already trying to say. Nobody asks whether you talked your ideas through with someone before you wrote them down. The difference is that the conversation partner is AI.

I use it for research. I used it to build things I couldn’t have built as easily on my own. I built an interactive Monday.com version of an Excel Gantt chart that’s changed how I manage projects. I used it on my job applications to assess fit before I invested time, to iterate on materials, and to push back when a draft read like something a machine wrote. When it did, I told the AI exactly how to rewrite it. The process is closer to editing through conversation than to receiving a finished thing. It is still work.

What this actually looks like, in any of these examples, is the same four-step loop: conversation, draft, iteration, critique.

I start with a conversation: what I’m trying to do, who it’s for, what I know about the context, what I’ve already tried. The AI drafts. I read what came back and tell it what’s wrong. The opening is generic. The third paragraph is making an argument I don’t actually believe. This sentence sounds like a machine wrote it.

The iteration is closer to instructing a junior staffer than to receiving a new draft. I name what isn’t working, point to a specific paragraph, explain why the framing falls flat, ask for a specific change. It comes back. I read again. The argument is sharper but the opening still drags, so I say so, and it tries the opening again.

Several passes in, I ask for critique: score this honestly, tell me what a careful reader would catch. On one of those cover letters, I asked whether it was being sycophantic after it scored a draft nearly perfect. It backed down, re-scored honestly, and named the weakness a real reviewer would catch. It’s the exchange that matters. The tool was correctable. I corrected it. It’s not outsourcing and it’s not cognitive offloading. It’s editing, and it’s work. It just looks different, and the output is better for it.

Would we ask someone not to use a template? Would we ask an accountant not to use Excel or Google Sheets because they’re a shortcut? Would we ask someone to do statistical analysis by hand to prove the work is theirs?

On the applications that asked me not to use AI, I disclosed that I had. A short italicized line stating that I used an AI assistant to brainstorm and draft initial structure, and that the analysis, arguments, and final writing are my own. I chose disclosure over concealment because concealment isn’t the honest posture, and because the “no AI” instruction, taken literally, pushes people toward hiding something rather than naming it.

The output tells you

Here’s the thing. You don’t have to restrict AI use, because poorly used AI shows up in the outputs. The unearned transitions. The throat-clearing openers. The vocabulary one notch fancier than how a person usually writes. The confident summary of something the writer never actually engaged with. The list of three when two would have been honest. Anyone who reads enough AI-generated text starts to recognize the cadence. It feels like the prose is performing thought rather than doing it.

Poorly used AI also shows up in what’s wrong on the page. Hallucinated sources. Statistics from the wrong year, presented as current. Citations to studies that don’t exist. This one is harder, because the writer may not catch it, and most readers can’t be expected to fact-check every claim. The AI presents wrong information with the same confidence as right information, and that’s a real tool problem, not just a user problem. I’ve written more about how AI systems break in social impact contexts — gaming, bias amplification, context collapse — and most of those failure modes also live in the outputs if you know what to look for. I’ve written about what AI is actually accelerating in the social sector, and the failure mode I see most is research done at speed without verification. A grant officer who treats AI output as a finished search instead of a starting one will chase a foundation that closed its program two years ago. A good researcher always starts with a question, not an answer. Using AI doesn’t change that. We don’t want to use AI to find evidence for a claim we already have. We want to use it to figure out what’s actually true, and then verify what comes back.

Good AI use shows up too. It shows up in the argument that’s sharper than it would have been. The research that was checked and pushed on, not accepted. The specific detail that nobody could have produced from a generic prompt, because the person sat with the tool long enough to find it. Standing at the window, waving, until the car was gone. That’s a sentence somebody had to remember. The AI didn’t know.

What to do instead

The fix isn’t to restrict AI use. It’s to ask the right questions of the right people. Three actions.

Judge the output. This is the action for anyone reviewing work. Instead of asking “did you use AI?”, ask for the work and read it closely. A hiring manager should look at whether the cover letter actually engages with the role or recites it back. A teacher should ask the student to walk them through their argument. A funder reviewing a proposal should look for the specific detail that proves somebody understood the problem before they wrote about it. The tells are visible to anyone willing to read closely. They were visible before AI existed. And don’t try to outsource the work to an AI detector. Those tools are notoriously unreliable, flag human writing as AI-generated, and miss the careful AI use you actually want to catch.

Disclose how. This is the action for anyone using AI in work that will be read or evaluated. Don’t hide it. A short, specific line is enough: I used an AI assistant to brainstorm and draft initial structure. I used it to sharpen the argument. The analysis, conclusions, and final writing are my own. That turns a hidden practice into a stated one, and it lets the reader weigh what they’re looking at. It also separates you from the person who pasted the prompt and submitted whatever came back. That person won’t disclose anything.

Cite and verify. This is the action for anyone using AI to do research. The AI will give you statistics from the wrong year and citations to studies that don’t exist, with the same confidence as the real ones. Until the tools flag their own uncertainty, the burden is on the writer to check. If you can’t cite it from a real source, don’t claim it. This is the action I want named loudest, because it’s the one most people skip.

The person who did the thinking will produce better work. The person who didn’t will produce slop, or generic prose, or confident wrongness. Those things are distinguishable. What isn’t distinguishable, and shouldn’t be penalized, is whether a thoughtful person used a tool to get there.

And maybe with the uncle, there isn’t a clean answer. Maybe the AI helped him sort through complicated feelings he couldn’t have organized on his own. Maybe it helped him grieve by giving him something to push against. Maybe it even helped him get the obituary written at all, on a deadline, when the emotional weight made the words impossible to find. I don’t know. The niece doesn’t know either. She’s furious because she imagines the worst version. But she doesn’t know which version it was.

And maybe the niece’s anger isn’t really about the AI. Grief looks for somewhere to land, and AI could simply be a convenient target. It’s a pattern I see often. The thing people are angry about and the thing they say they’re angry about don’t always match. AI is loud and unfamiliar and easy to name, and naming it is easier than sitting with the harder feelings underneath. That’s worth saying gently, because the impulse is human, and because none of what I’ve written here is meant to dismiss it.

But it does mean the question on the table should be a fair one. Go back to the uncle. Read the obituary. If the writing carries his mother in it, if the details could only have come from someone who knew her, then he sat with the AI and did the work. If the obituary could have been written about anyone, he didn’t. The writing tells you. You don’t need him to.

That’s the only question worth asking. Not whether. How. And the answer is in front of you, on the page.

The uncle is one example. The schools are another. The applications are a third. The pattern is the same in every case: we’re using a screening question that can’t tell us what we actually need to know, and the cost of getting it wrong is that we punish the people doing careful work and let the careless ones through.

AI isn’t going away. We can keep pushing blindly against it, or we can learn to use it well, cut the slop, and teach other people how to use it well too. That’s the choice on the table. The version where we ban it doesn’t exist. The version where we pretend it isn’t already in everyone’s workflow doesn’t exist either. What exists is a tool that some people are using carelessly and some people are using carefully, and a screening question that can’t distinguish between them. The people who lose out will be the ones who refused to engage with it at all.

So replace the question. Judge the output, disclose how, cite and verify. That’s the version that’s worth our time.

Anthralytic is a strategy and evaluation studio for mission-driven organizations. If you make decisions about resources in the social sector, whether or not you call yourself an evaluator, this newsletter is for you.

I read the announcement twice. The second time, I recognized it. Not from anything in technology. From international development.

I have watched this approach fail before

For most of the last century, international development ran on a particular assumption. “Expertise” lived in the capital, or the donor country, or the consulting firm, and it traveled outward to places that had problems but not answers. The expert arrived with a solution that had worked somewhere else. The local context was treated as a setting for the solution rather than a source of one.

The results are well documented. Schemes that ignored how things were actually done on the ground. Tools nobody adopted. Programs built around problems the community would not have named first. The failures were rarely failures of the tool. They were failures of a direction of travel. Knowledge was assumed to move one way, from the people who held the method to the people who supposedly just had the need.

The field has spent decades trying to unlearn this. Simply put, participatory development was the answer to that problem. It started from a simple reordering: the people who live inside a problem understand it in ways an outsider cannot, and any solution that does not begin with their knowledge will ride roughshod over the parts that matter. Outside expertise still had a place. It just had to earn that place on local terms, in service of knowledge that was already there.

I spent more than a decade inside that world. I know how hard the lesson is to learn and how easily it gets forgotten.

Who has the expertise?

Using AI well is a real expertise. It takes time to build and it does not come free. I am not saying the tool side is easy. I am saying there are two expertises here, the tool and the mission, and the program is built as if there is only one.

But, it does not even fund that one well. The fellow is a young professional with under two years of work experience, selected not for tool expertise but for comfort and judgment from daily use of Claude. The base camp training is a reasonable on-ramp for a newcomer. It is a one week pre-placement training covers prompt design, building with the API, and running an AI evaluation and about five hours a week after. There is no training in the work of the organizations these fellows will enter. It is not the making of an expert in anything. Anthropic is explicit that it is not looking for sector expertise, only comfort and judgment from daily use of Claude. The fellow arrives as fluent as one can get in Claude in a one-week training and learns the mission on the job. So the program does not actually deliver deep tool expertise either. It delivers a junior person with a week of orientation, positioned as the AI authority in the room.

There is a deeper asymmetry underneath the training gap. The tool side, thin as it is, still gets a dedicated person, full-time, for a year, with a salary behind them. The mission side gets no new hire at all. It stays with a staff member who already had a full job, and who now has to add managing that newcomer on top of it. And the fellow will take what they learn and move on when the year ends. The program is not just under-resourcing the domain side. It is treating the domain knowledge as something a smart outsider absorbs on the way to the real work, while the tool gets treated as the expertise worth a salary and a year.

This is familiar. It is the exact assumption international development is still grappling with. The outsider arrives certified in the method, and the place they land is treated as the setting where the method gets applied rather than as knowledge that should shape what gets done in the first place. The method is the expertise. The community is the backdrop. Claude Corps rebuilds that same hierarchy.

The inversion shows up again in who decides what the fellow works on. To be eligible to host, an organization does not even need a project in mind. Anthropic’s own guidance says that if something is slowing your team down but you have not figured out the AI use yet, that is fine, because Anthropic helps with project discovery before the fellowship begins. The whole arrangement runs on an assumption that is never tested: that AI is the answer. Maybe it is, for a given problem. Maybe it is not. But a program that places a Claude-trained fellow first and looks for the problem second has already decided the question that domain knowledge exists to ask. It is a hammer looking for a nail.

The program is built around the model, not the nonprofit

There is an obvious way to build this if the goal is the host’s mission. Take someone the organization already trusts, someone who knows the work, and train them in the tool. That person exists. The program calls them the supervisor. Instead the program imports a newcomer trained in Claude and asks the supervisor to direct them in the margins of an already full job.

The reason it cannot take the obvious path is in the eligibility rules. Anyone over eighteen with under two years of full-time work experience can apply, regardless of educational background. The hard filter is a workforce filter, early-career and new to the workforce, not a mission filter. The program screens out the people best positioned to bridge a tool to a sector, the ones who already carry a sector in their hands, because the fellow being a new entrant to the workforce is not incidental. It is the design.

That points to what the program is actually organized around. Read the structure as the answer to a single question, how does Claude take root in four hundred nonprofits, and every feature falls out cleanly. Fellows trained only in Claude. Hosts required to be paying Claude for Nonprofits customers before they can receive a fellow at all. Workflows built around Claude that keep running after the fellow leaves. A fresh entrant rather than a sector veteran who might conclude the tool fits in a smaller way than hoped. None of these follow from what would most help this organization. All of them follow from how the model spreads.

I have watched this structure before, pointed at a different group. Last fall I wrote about Microsoft, OpenAI, and Anthropic launching an academy to train hundreds of thousands of teachers in AI. I said then that training is often product onboarding in disguise, and that the effort was honestly about two things at once, preparing students and expanding markets. Swap teachers for fellows and classrooms for nonprofits and the shape is the same. The people being trained are real, the help is real, and underneath it the model gets a generation fluent in it as the default way the work is done.

This is not the design of a program whose top level goals are aimed at the intern nor the nonprofit. So the honest version of the question is not whether the fellow benefits, or whether the host benefits. Both can be true. It is whether anyone designing this started from them. The fellow’s career and the host’s mission read like outcomes the program would be glad to produce on the way to the outcome it was built for. When a workforce program is genuinely for its workers, or a capacity program genuinely for the organizations, you can see it in what the design refuses to compromise. Here the thing held constant is the model. Everything else bends around it.

The correction development already found

Participatory development doesn’t tackle this by rejecting outside expertise. It tackles it by changing the direction of travel. The knowledge that organizes the work belongs to the people inside it. Whatever comes from outside has to bend toward that knowledge, not the reverse.

Applied here, the reordering is straightforward. The person bridging AI and a nonprofit’s work should start from deep knowledge of that work: what the organization is trying to do, who it serves, what its data actually represents, where the hours really go, what would break if you automated the wrong thing. From there, they reach toward the tool, learning enough to judge where it fits and where it does not. That judgment cannot be installed in a base camp. It is the accumulated knowledge of the domain, and the program treats it as the part that takes care of itself.

That is not the harder version of Claude Corps. It is the inverse of it. Same two expertises, opposite ordering. I have written before that AI is most useful when you manage it the way you would manage a junior staffer, where your judgment, your framing, and your knowledge of your own context are the things that do not automate. That only works when the judgment comes first and the tool answers to it. Claude Corps runs the relationship the other way.

What it looks like to build from this side

The other ordering is not hypothetical. It is what I am building Anthralytic toward. This piece is not about that, and if you want to read more you can go to anthralytic.com. The point is only that the reverse direction can be built: a platform whose methods a practitioner designed, with a human expert kept in the loop where field knowledge matters most, so the domain knowledge is the thing the tool is built out of rather than something bolted on afterward. The mission knowledge sets the terms and the technology is shaped to serve it. That is the opposite ordering from a fellow trained in a model and sent to find a use for it.

I am not neutral here. I’m building something that argues against the direction Claude Corps travels. And I’m building it on the same models Claude Corps would deploy. The complicity is real and I would rather name it than pretend to stand outside it. But the argument does not rest on my positionality. It rests on a lesson international development paid for over decades and is now positioned to relearn through AI.

If Anthropic wanted to build it the other way

There is a version of this program that starts from the nonprofits. Here is what it would change.

Instead of recruiting newcomers and training them in Claude, borrow the people who already know the work. Every host has staff who understand the mission, the data, the constraints, and the communities. Take one of them out of their regular load for the year, full-time or half-time, and train them in the tool. Have the fellowship pay for the share of their salary the organization is no longer covering. They are already embedded. They already passed the hard test, the one no base camp can teach, which is knowing the work. Add the tool to the expertise rather than adding the expertise to the tool.

Then evaluate it honestly. The current plan puts measurement and evaluation in the hands of the program’s own partners, scoring whether host organizations advanced their missions. An honest design would hold out a control group, a comparable set of organizations that receive no fellow, so the gains can be told apart from what the organizations would have managed anyway. And it would measure more than Claude usage. How much Claude gets used is the easy number, and it is the wrong one. The question is whether outcomes improved for the people the organizations serve, which is the measurement the sector keeps mistaking velocity for. Counting tool adoption and calling it impact is the same error one layer up.

Anthropic can keep its adoption goal. The whole structure is built to drive usage, which is plain enough that I was able to reverse engineer the strategy from the eligibility rules and the host requirements alone. There is nothing hidden about it. But a program cannot serve two masters and measure for only one of them. If helping nonprofits is a real goal alongside spreading the model, then nonprofit outcomes have to be in the measurement as a priority, not as a line Social Finance reports at the end. What gets measured is what the program is actually for. Right now that is adoption.

None of this is more expensive than what is already committed. It is the same money, pointed at the sector instead of the model. It would be harder to scale into a clean replicable unit, and it would be slower, because the people who know the work are not interchangeable the way a base camp cohort is. That difficulty is the tell. The friction is exactly the sector’s real texture, the thing the current design smooths away by importing a standard newcomer instead.

The nonprofit sector does not need the old mistake in a new coat. It needs the bridge built from the side that already understands the work. If Anthropic wants to help the nonprofit world, that is where to start: with the knowledge that is already there, and the honesty to measure whether anything actually changed for the people it was all supposed to be for.

Leave a comment

Share

Anthralytic is a strategy and evaluation studio for mission-driven organizations. If you make decisions about resources in the social sector, whether or not you call yourself an evaluator, this newsletter is for you.

Anthralytic is a strategy and evaluation studio for mission-driven organizations. We work at the intersection of measurement, impact, and decision-making systems, including the ones nobody voted on.

Not a slow rollback. Not a voluntary pause. A letter from Commerce Secretary Howard Lutnick to CEO Dario Amodei, received at 5:21pm ET on June 12, directing Anthropic to suspend all access to Fable 5 and its restricted sibling Mythos 5 for any foreign national, anywhere in the world, including Anthropic’s own employees. Anthropic couldn’t filter users by nationality in real time. So they shut it down for everyone.

Fable 5 was Anthropic’s first public release built on Mythos, its most capable and restricted model class, previously available only to a small group of government-vetted organizations through Project Glasswing. This is the first time the US government has used pre-deployment authority to pull a commercially deployed AI model from the market. The precedent is the story.

The Same Vulnerability, A Different Outcome

The stated reason for the shutdown was a jailbreak. A specific technique for bypassing Fable 5’s safeguards, identified by what David Sacks described as “a highly trusted partner trusted by both Anthropic and the US government.” Sacks, co-chair of the President’s Council of Advisors on Science and Technology, said the fix was straightforward: patch the vulnerability and Fable can go back online.

Anthropic’s response was that the jailbreak was narrow. Not a broad bypass of the model’s capabilities, but a specific technique that worked in limited circumstances. And then the detail that should stop anyone reading this: Anthropic said the same vulnerability existed in other publicly available models, including OpenAI’s GPT-5.5.

Those models weren’t touched.

One company gets a Commerce Secretary letter. A named competitor, with a documented version of the same vulnerability, keeps operating. That is not a safety standard being enforced. A safety standard applies to the hazard, not to the company. When the same hazard produces a shutdown for one firm and nothing for another, what’s being applied is discretion, and discretion wearing a safety justification is harder to challenge than discretion that admits what it is.

Anthropic has called for oversight that is, in their own words, transparent, fair, clear, and grounded in technical facts. What they got was an undisclosed national security concern, a letter with no specifics, and a deadline measured in hours.

The Backdrop Nobody Should Skip

This didn’t happen in a vacuum. In March 2026, the Department of Defense classified Anthropic as a “supply chain risk”, a designation Anthropic was contesting in court. The conflict reportedly centered on Anthropic’s refusal to make Claude available for mass domestic surveillance and fully autonomous weapons systems without restriction.

So when a narrow jailbreak becomes the basis for a global shutdown of a single company’s model three months later, the question of whether this is a genuine security measure or pressure on a company that said no is not paranoid. It’s the obvious question. And the public record cannot answer it, because there is no record. No published finding, no technical disclosure, no process anyone outside two organizations can see.

That opacity is the point. A legitimate safety action can survive being examined. This one is structured so it can’t be.

Is Anthropic a Sympathetic Victim Here?

Worth pausing on, because the answer isn’t clean.

Anthropic confidentially filed its IPO prospectus with the SEC on June 1, eight days before Fable 5 launched. A company heading for a public offering has every reason to look like the responsible adult in the room, and “we called for our own regulation” is a good line for investors nervous about a government crackdown. Some of the safety positioning is, undoubtedly, positioning.

But the record runs deeper than IPO season. Anthropic disclosed that Chinese state-sponsored hackers used Claude Code to run what they called the first documented large-scale cyberattack carried out without substantial human intervention. They didn’t have to. A researcher extracted what Claude itself called a “soul document” from the model weights, and rather than deny it, Anthropic’s character lead confirmed it was real. Dario Amodei has twice called for AI companies, his own included, to be taxed to fund support for workers AI displaces. Days before the shutdown, he published an essay calling for exactly the kind of government authority to block dangerous models that was then used against him.

You don’t have to find Anthropic noble to see the problem. The argument here doesn’t depend on Anthropic’s sincerity. It depends on whether the government followed a process anyone can inspect. It didn’t.

This Is the Dark Mirror of an Argument I’ve Made

I’ve written before that voluntary AI governance can’t handle what’s coming, that we need real oversight with mandatory reporting, audits, and enforced constraints, the way we regulate food safety rather than trusting processors to self-certify. I still believe that.

The Fable 5 episode is what that argument looks like when it goes wrong. Oversight arrived. It just arrived with no published standard, no technical basis anyone can review, no process to challenge, and a curiously selective target. This is the version of government authority that should worry the people who want government authority. Because it discredits the legitimate case for it.

Real oversight and arbitrary power both look like a letter from the Commerce Department. The difference is whether there’s a standard behind the letter, applied evenly, that the public can see. Strip that away and you don’t have governance. You have whoever holds the authority, using it, on whatever basis they choose, against whoever they choose.

What Compliance Buys You

Here’s the question that outlasts this particular shutdown. If the most safety-focused major lab can be pulled from the market on a narrow jailbreak that its competitors share, with no process and no published reason, what exactly does compliant behavior buy a company?

The honest answer right now is: not much. Transparency didn’t protect Anthropic. Disclosure didn’t. Calling for regulation didn’t. The next time a lab finds something alarming in its own model, the Fable 5 precedent is sitting there as a reason to keep quiet, because candor and cooperation were rewarded with a kill switch.

That’s the real cost, and it isn’t Anthropic’s to bear alone. It lands on everyone downstream who depends on these tools and has no say in any of this. Including the social-sector organizations building real work on top of models that can vanish by end of business on a Thursday.

The question of who gets to decide which AI is too dangerous doesn’t have a good answer yet. What this episode tells us is what the answer can’t be allowed to become: a letter, no standard, no process, no appeal, and a different rule depending on which company you are.

Anthralytic is a strategy and evaluation studio for mission-driven organizations. We work at the intersection of measurement, impact, and decision-making systems, including the ones nobody voted on.

Leave a comment

Share

AI is succeeding at accelerating the wrong things. The dominant report measures the acceleration as impact. The companies producing the evidence base are the companies selling the tools. The frame is built so that the question that matters never gets asked.

This piece is the constructive turn, and it offers three things in response. A question worth holding, a practice worth starting, and a demand worth making. One conceptual, one personal, one political.

The risk in a piece like this is naivete, the temptation to overstate what one practitioner or one studio or one newsletter can do. I will try not to. What follows is not the answer but rather the beginning. It is the shape of the answer the field will have to build, and three places to start.

We do not know where the time goes, because no one is asking

A word on evidence first. While drafting the first piece in this series, I went looking for research on where AI-saved time actually goes for nonprofit workers, and what happens to the people the work exists to serve.

The cross-sector evidence is mixed. A Zoom survey early this year found most knowledge workers saving thirty minutes a day or more and using it for breaks and life outside work. A Berkeley Haas ethnographic study in Harvard Business Review found the opposite, a workday that expanded to fill whatever AI freed up. A Workday survey found close to forty percent of saved time going back into fixing what AI got wrong.

The nonprofit-specific evidence is thinner. A 2025 systematic review of AI-assisted case management in social work measured decision accuracy, not relational quality or client experience. The adoption report measures self-reported efficiency. None of it asks where the time went or who is better off.

The honest version is that we do not know, because no one is asking in the right places. What follows is what asking would look like.

A question worth holding: Who is better off?

The first move is conceptual. Run every conversation about AI in your organization through one question before any other. Not whether to use AI. Not whether you are falling behind. When this organization adopts this tool, who is made better off, and how would we know.

Three groups could plausibly benefit: the people the organization serves, the workers doing the work, and the mission itself—the work that does not fit a dashboard but that the organization depends on.

The vendor frame collapses all three into a single number, organizational capability measured as fundraising velocity, and calls it impact. The question of who is better off refuses that collapse. It is the question Nicole Bowman’s Indigenous evaluation work has been asking for decades: evaluation as a relational act, carried out with communities as relatives rather than performed on them as subjects. This is not woo-woo stuff. This is the purpose of the work. Treating the people the work is for as the people who get to say what the work is doing is the move the field has been organized to avoid.

Carry the question into every AI conversation you are in. It changes what gets said.

That is the place for a pre-mortem. Before adopting a tool, imagine it is a year on and the decision went badly, then work backward to name how it failed: whose work got heavier, what got automated that should have stayed human, which relationship with the people you serve quietly thinned. A pre-mortem costs an hour and surfaces the parts of the trade the vendor’s demo is built to leave out.

The tools that most need a pre-mortem are the ones no one ever decided to bring in. Microsoft Copilot does not arrive through a procurement conversation. It arrives switched on, inside a license the organization already pays for, and that is exactly how it slips past the question. A tool you did not choose to adopt is a tool you are adopting anyway. Run the pre-mortem on that one too.

A practice worth starting: ask your workers where the time went

The second move depends on where you sit. If you manage people, you can start it this week, without waiting for a funder or a perfected methodology. Ask the people who report to you where the hours AI is supposed to be saving them are actually going.

Ask carefully, though, because the question is less neutral than it sounds. To the person answering, you control their workload, and admitting that AI saved them three hours can feel like handing you a reason to fill those hours. In this sector especially, saved time has a way of becoming more work, so honesty carries a risk, and you will get the safe answer instead.

Take that risk out. Make it voluntary and anonymous, run it through a survey or a facilitator outside the chain of command, and report back in themes rather than named responses. Say plainly what it is not: not a productivity audit, not an input to anyone’s review, not a pretext to add work or cut a role. Then go first yourself, and name where your own time went.

The questions are simple. Ask whether the work got more fulfilling or less, whether the caseload grew, whether they are working fewer hours or the same hours with more output, and whether AI gave back the relational parts of the job or took them. Ask the people the organization serves a version of the same, where that can be done without imposing: whether they could tell when something was AI-generated, and whether they felt known.

What matters most is what you do with the answers. If someone got an hour back, the test is whether the hour stays theirs. Fill it and you have proven the fear right, and you will not get an honest answer again. The time was supposed to go somewhere that mattered, and the worker is one of those places.

If you do not manage anyone, the practice turns inward. Track where your own saved time goes, and notice when AI quietly widens your scope, when the hour it gave back fills with work you did not used to carry. Protect that time where you can, name the pattern to the people who can change it, and when someone runs the question by you, answer it honestly. The leader’s version only works if someone is willing to tell the truth. None of this is rigorous in the standard sense. It is what one organization, or one person, can do now to refuse the vendor’s frame.

A demand worth making: independent evaluation, funded outside the vendors

The third move is political, and it is not addressed to practitioners. It is addressed to funders, to evaluators willing to organize, and to researchers willing to do the work that does not yet exist.

The most concrete piece of it is this. The sector needs rigorous, nonprofit-specific study of how AI adoption is affecting the workforce, with attention to who. The Berkeley Haas study is the closest analog, and it documented a corporate workforce expanding its workload to fill the time AI freed. The nonprofit sector has nothing equivalent, and the differences matter. The martyr effect does not land evenly. International consultants and local staff. Headquarters and field. Frontline workers, fundraisers, evaluators, directors. Each carries a different expectation of what commitment costs, and AI will land on each one differently. Some will reclaim time. Some will absorb expansion. Some will lose hours to cleanup while held to the same targets. We do not know who. We should.

The method would be longitudinal and mixed, with the qualitative treated as primary, and it would be built with the communities the work serves rather than on them, the relational stance Nicole Bowman’s work has spent years arguing for. Julian King’s Value for Investment is the closest cousin in the standard literature, because it refuses to reduce the evaluative question to cost alone and asks what is worth investing in, by whose criteria, and for whose benefit.

This has to be a demand because it is structural. The evaluation architecture funders spent thirty years building, the one that produces clean metrics on tight reporting cycles, is incompatible with what honest AI assessment requires. The funder has to choose. AI did not create that problem. It made it visible at a speed the field can no longer pretend not to see.

I know where the seams are, and I am building toward the other side

I worked within cooperative agreement structures for years. I knew the evidence base for what worked was being produced by the people who benefited from it working, and I reported against those benchmarks anyway, because that was the work being paid for. I am not outside the system I am describing. I am the person who knows where the seams are.

Anthralytic exists, in part, to do the work the vendor-produced research will not. The Conditions Web maps conditions across eight domains of social reality before an organization designs strategy or evaluation. The How AI Breaks in Social Impact tool teaches the failure modes the sector is currently absorbing without naming. A Rapid Evaluability Scorecard tests whether a program is ready to be evaluated at all, and an Impact Wizard helps a team build a theory of change. These are not the answer. They are free, practitioner-scale moves toward the questions the field’s architecture is not asking. I name this as positioning, not a pitch.

The improvement is real only if it reaches the people it was for

The improvement is real only if it is an improvement for the people it was supposed to be for. The current architecture does not check. The next one has to.

The harder work starts here. With the practitioners willing to ask. With the funders willing to pay. With the communities willing to say what they have seen.

Previous pieces in this series:

Who is Better Off When AI Speeds up the Workflow?

Measuring the Wrong Thing Faster

Grading Their Own Homework