Someone called another AI session afterward. The format was more of a conversation than the previous one-way presentation had been and we shared tools and methods. People described what they were trying, where AI had helped, and what they were learning. In my own evaluation practice, I’ve used it to develop accessible materials and participatory tools that help people shape an evaluation. It can also help us work through qualitative responses and larger bodies of information, provided we check the analysis and preserve context. Tools like Gemini Notebook can make dense material more accessible for some people with dyslexia by offering a way to engage with it through audio. For organizations and individuals facing constraints on time, money, or access, these benefits deserve serious consideration, even when they come with limitations.

I understand the weariness around AI, and I encounter it at work too. People are tired of slop, worried about their jobs, concerned about privacy, and uncomfortable with power accumulating in a handful of companies. Some of these problems existed before AI, but AI can make them worse. That gives us more reason to examine what is actually happening. Data centers support much of our digital life, and AI adds demand; possible environmental benefits need evidence and don’t erase present costs. Privacy requires attention to the information we enter, the systems we use, and the protections in place. Bias requires us to examine whose experience is represented and what happens when a system gets something wrong. A useful application can still carry unacceptable costs, but reaching that judgment takes more than a blanket statement about AI as a whole.

At work, people encounter frustrating tools without much support for defining a task, supplying context, or judging the result. It’s easy to request a complete deliverable in one prompt and receive a 26-page document. But that doesn’t make everyone more productive. Now someone else has 26 pages to read. Producing more material is hardly an accomplishment if it creates more burden. In my last piece, I described AI as a paintbrush, and that metaphor still feels useful: the person holding it needs purpose, practice, and judgment. We need opportunities to learn how to work in manageable steps, check claims, protect information, and decide whether the result serves anyone. That education should also help us recognize when to put the tool down.

I want schools, libraries, workplaces, and professional associations to take this need seriously, with independent leadership shaping what gets taught. In my earlier piece on big tech’s role in AI education, I explored the promise of companies helping teachers learn these tools, alongside the risk that training becomes product onboarding and schools grow dependent on particular platforms. That tension matters beyond the classroom. Companies benefit when we adopt their products and keep using them, while education needs room to question their claims, compare alternatives, and conclude that a particular use should be avoided. Educators, researchers, workers, and affected communities should help set those priorities. We also need to collectively figure out how to teach children within this changing landscape, giving them opportunities to use AI to ask questions, practice, and develop understanding alongside work that requires them to think without it. They need to recognize when assistance supports learning and when it bypasses the thinking they need to do. Adults need that discernment just as much. I want people to have enough knowledge to make choices they can explain and defend, including the choice to work without AI. That capacity takes thoughtful teaching, and we have plenty of reasons to begin.

Anthralytic builds practical software for mission-driven organizations. Our tools make evaluation, strategy, and learning more accessible, helping teams explore evidence, involve the people affected by their work, and make informed decisions.

Share

Leave a comment

If you have read my work before, you have probably read something that AI helped me write. I tell you when it has. What I haven’t told you is what “helped me write” actually means.

I have written about this before, most directly in “I Used AI to Help Write This Piece. Judge the Output.” My argument there was that asking whether someone used AI tells us almost nothing. The better question is how they used it. Consider this the longer, more personal answer to that question: the how of my own writing process.

You might imagine that I type a prompt asking ChatGPT to write an article, wait a few seconds, and paste the result into Substack. I have tried something like that. The result was garbage.

It wasn’t incoherent. That was almost worse. It had paragraphs, transitions, and the shape of an argument. It looked like an article. What it lacked was a reason to exist. There was no curiosity pulling it forward, no process of discovery underneath it, and no person making deliberate choices about what was worth saying. The prose was performing thought rather than doing it.

Writing well with AI is much more involved—and much more human—than that. (Did you like the em dashes? I left them in for you.)

When I use AI, I begin with something I want to say or something I want to understand. From there, it becomes a research assistant, a sounding board, an editor, a skeptic, and a writing partner. It introduces ideas I had not considered and asks questions that make me examine what I think I know. Because I ask it to.

It has also changed something more personal about writing for me.

I think I am a good writer without AI, but I am a slow one. I have always struggled with freewriting because my internal editor arrives before the thought has fully entered the room. I stop over the wording, correct the punctuation, rearrange the sentence, and then edit it again. By the time the sentence is polished, I may have lost the thought that was supposed to follow it.

I don’t do that nearly as much anymore. I type quickly without worrying about spelling or punctuation, trusting that we can organize the material later. Sometimes I take ChatGPT on a walk and talk through an idea as it develops. I contradict myself, wander down the wrong path, circle back, and say things badly. The thought is allowed to arrive before I decide what clothes it should wear.

Now there is a clearer line between the flow and the edit. The cleanup is easy. Recovering a thought I edited out before I ever expressed it is not. AI has given me permission to separate exploration from polish, and that freedom has made writing more fluid. It has also made my thinking more expansive. I can follow an idea before deciding whether it belongs. I can see what is there before I begin cutting it into shape.

The stranger thing is that this practice has begun to change me. My thoughts become coherent sooner. I see the structure of an argument earlier than I used to. The tool is not only helping me organize the writing after the fact; something about the repeated process of talking, questioning, arranging, and rearranging is teaching my mind to organize itself differently. I find that fascinating.

It starts with something unsettled

When I write with AI, I begin with one of two things: a statement I want to test or a question I want to explore.

The statement is not necessarily the thesis of the eventual piece. It is closer to a proposition: something I suspect might be true but have not earned the right to claim yet. The question is more open, although questions carry assumptions too. In both cases, I begin with uncertainty.

Then I research.

There are usually several rounds. One answer reveals another question, which opens a part of the subject I had not considered. I ask for sources, follow the trail (AKA read them), and ask where the evidence disagrees (and read those too). I almost always ask some version of: How might this research be biased? What am I missing? Whose perspective is absent? What evidence would challenge the direction I seem to be heading?

That matters because AI can be too agreeable. If I ask it only to support a position, it can usually find a way to do that. It can also give me a statistic from the wrong year or a confident summary of a source that says something more qualified when I actually read it. AI research is a beginning, not a finished search. The responsibility to cite and verify does not disappear because the search happened faster.

I do not want a writing partner that simply tells me my idea is brilliant. I want one I can ask to keep me honest.

The initial research gives me material, but it usually does not give me the piece. For that, I have to explore.

Then comes the conversation

This is the part of the process I initially had trouble naming. I thought of it as conversation, which sounded different from writing. Then I thought of it as freewriting, which wasn’t quite right either.

It is both.

Sometimes the conversation is typed. Sometimes it happens aloud while I walk. ChatGPT is better for that at the moment. I bring in what I found during the research and begin turning it over. I say what seems important, what bothers me, where the evidence does not fit together, and what I think might be underneath it all. AI reflects the argument back, and I tell it where the reflection is distorted.

No, that isn’t what I mean.

That conclusion is too neat.

You are agreeing with me too quickly.

What happens if we look at it from the other side?

The exchange is exploratory in the way freewriting is supposed to be exploratory, but it answers back. I am not alone on the page waiting for my own next thought to appear. There is something on the other side of the sentence, offering a connection, asking a question, or occasionally misunderstanding me in a way that clarifies what I meant.

The misunderstanding can be useful. So can the disagreement, when I ask for it. Even the sycophancy tells me something, because pushing against an answer that is too flattering forces me to state the argument more precisely.

This conversation almost always leads back to more research. A claim that sounded plausible needs evidence. A missing perspective opens another line of inquiry. A source complicates the thing I thought I believed, so I return to the conversation with a different set of facts. Research feeds exploration; exploration reveals what else needs to be researched. The movement is circular, or perhaps spiral: I return to the same question, but each time with a little more context.

This is the real discovery phase. The thesis comes later.

The thesis is something I arrive at

Eventually, after moving between research and conversation for a while, I land on the angle. I begin to see not only what I have found, but what I want to say about it.

That is when I write the thesis.

If I began with a statement, the final thesis may resemble it, although it is usually narrower, more qualified, or pointed in a slightly different direction. Sometimes I discover that the original statement was only partly right. Sometimes I realize it was not what I wanted to say at all.

If I began with a question, the thesis is the answer I can now defend—or at least the most honest answer I can offer with the information I have.

Research gives me information. Exploration lets me find the pattern. The thesis is the claim I am willing to make about what that pattern means.

Only then do I build the outline.

If the conversation has already become extensive, I may ask AI to derive an outline from what we discussed. Other times, I give it the broad swaths of what I want to cover and ask it to arrange them. Either way, I almost always change what comes back.

I move sections. I remove ideas that are interesting but non-sequiturs. I notice when an essential point is missing or that I am asking the reader to accept something before I have earned it. I check that each section is doing work on behalf of the thesis rather than merely sitting nearby looking relevant. Often those non-sequiturs become their own posts.

The outline is not the authority. It is a proposal.

At this point I also almost always write the title myself. The title of this piece is mine. That matters because a title is not just packaging; it is the most compressed expression of what I think the piece is about. If I cannot name the piece, I may not yet understand what I am trying to say.

Drafting is still discovery

Once I am satisfied with the outline, I usually ask AI to generate the text one section at a time. Before it drafts, I explain what the section needs to accomplish, which parts of the research belong there, and how it should connect to the larger argument. Then I respond to what it gives me.

I cut sentences, rewrite passages, add context, and tell it when the language sounds generic or when it has made the argument cleaner than the truth allows. Sometimes it finds a way to express something I had been struggling to articulate. Sometimes it produces a polished paragraph that is not actually true to what I think.

A well-formed sentence can still be the wrong sentence.

The exploration does not stop because drafting has begun. I may reach section four and realize that section two needs to change. A new connection may send me back to a source, and that source may alter the thesis again. The outline bends. Earlier paragraphs move. Something I thought was central becomes a footnote, while an idea I nearly discarded becomes the heart of the piece.

That is not a failure of the process. It is the process. Writing has always been a way of discovering what we think, and AI should not remove that discovery. Used well, it gives me something to think against throughout it.

The draft grows through a continuous exchange among research, conversation, structure, and prose. The stages are real, but their borders are porous. Research changes the argument; the argument changes the outline; the draft reveals a gap; the gap sends me back into research. Each pass leaves the piece a little different, and if the process is working, it leaves me a little different too.

Then I become the reader

After the complete piece is drafted, I read it several times. I look for the places where it says something adjacent to what I mean rather than what I mean. I look for repetition, missing transitions, and claims that have grown stronger than the evidence supporting them. I ask whether every section contributes to the thesis and whether the piece holds together as a whole.

After I have done my own reading, I often ask AI to roast the draft. I discovered this while building a pitch deck and wrote about it in “Roast This Post.” The feedback had been helpful but a little too polite, so I typed, “roast this slide.” Suddenly the model stopped nudging and started telling me what was repetitive, vague, overworked, or simply not landing.

The word roast does not make the model smarter, but it changes the role I am asking it to play. Where did I bury the point? Which paragraph is doing no work? Where am I using polished language to hide an unfinished thought? I do not accept every criticism. Sometimes I argue. But that is part of the value: the exchange makes me defend the choices that deserve to stay and reconsider the ones that don’t.

Sometimes I put the draft into a different model for another review. If Codex helped me write it, I may ask Claude to critique it; if Claude helped with the draft, I may bring it to Codex. Usually Claude is the reviewer. (I have not found Gemini nearly as useful for writing or reviewing, although other people may have a different experience.)

A second model is like bringing in an editor who was not in the room for all the earlier conversations. It has not grown accustomed to the draft’s assumptions, so it may notice something the first model and I have stopped seeing. I ask it to identify the weakest section, tell me what a skeptical reader would challenge, and point out where the argument sounds more certain than the evidence allows.

Sometimes the piece goes through three or four drafts. When the argument finally feels settled, I ask AI to copy edit it. Then I read it again, make more changes, and paste the finished version into Substack.

You may be noticing something familiar here. Research, conversation, drafting, revision, feedback, more revision. This is not entirely unlike the age-old process of writing.

You are right.

Writers have always talked through ideas, worked with editors, reorganized arguments, rewritten paragraphs, and discovered halfway through that the piece they thought they were writing was not the piece they needed to write. AI has not eliminated that process for me. It has made the process more conversational, more available, and sometimes more rigorous. I have access to a partner I can question whenever the thought begins to move.

The important part is that I remain in the room.

So, what is the point, you may ask. First, it’s faster. It takes me about a quarter of the time as it would have to go through this process. Second, it enhances my writing. It keeps me honest, and brings in points I hadn’t considered. And third, it’s pleasurable. It just is. I’ve always loved to learn, and using AI as a writing partner makes learning so damn fun. That’s why I do it.

I am the human and the driver

Does this process sound like cognitive offloading to you? Because it actually feels more rigorous than the writing I did in college. It is my question or proposition that starts the process. I direct the research. I decide which evidence matters and what the evidence can reasonably support. I choose the argument, shape the structure, write the title, and determine what stays.

AI contributes ideas, connections, criticism, structure, and language. Sometimes it formulates a sentence better than I would have. I have the humility to say that its contribution is real.

But I accept or reject thecontribution. I decide what I believe. I put my name on the piece, which means I am responsible when it is right and responsible when it is wrong.

That is why the complete-article prompt produced garbage. I had temporarily removed the part of the process that gave the piece purpose: myself.

What does “90 percent AI” mean?

I am transparent about my use of AI. I do not use it to write every piece, but when I do, I select the disclosure that says AI helped me write it.

Substack also has a feature called Scan for AI text, which uses a tool called Pangram to estimate what percentage of a piece is human-written or AI-assisted. My pieces often come back as more than 90 percent AI.

I am not entirely sure that is how I would assess them.

Did AI formulate many of the final words? Yes. If I paste the copy-edited version from the canvas into Substack, I understand why a detector sees its fingerprints everywhere. At the sentence level, maybe the percentage makes sense.

But the number cannot tell you who formed the question, directed the research, asked about bias, noticed what was missing, rejected a weak argument, or changed their mind. It cannot tell you who decided the piece was worth writing. A detector can examine patterns in the finished prose; it cannot reconstruct the intellectual history underneath it.

That does not mean AI made no meaningful contribution. It means authorship is more complicated than counting who formulated each word.

I am being changed by it

The most interesting part of this process is not that AI helps me produce a polished article more quickly. It is that working this way is changing how I think.

Because I regularly ask AI to test my assumptions, I have become more likely to look for them myself. Because we organize arguments together, I see their structure sooner. Because I repeatedly ask what is missing, I am more conscious of absent perspectives before I reach the end.

The conversation is slowly moving inside my head. I begin anticipating the questions before I ask them.

Better organization in my writing has brought better organization to my thoughts, which is why I do not experience this as offloading my brain. I experience it as enhancing it. The distinction matters. Offloading would mean asking the machine to think so that I do not have to. This process asks me to keep thinking: to respond, evaluate, resist, choose, and sometimes begin again.

That does not make the influence automatically good. AI can make a weak argument gleam. It can smooth away the strange and distinctive parts of a voice. It can reinforce the premise of a question instead of challenging it, and it can be confidently wrong. Writing well with AI requires an awareness of those tendencies and a willingness to push back against them.

The goal is not to surrender judgment. The goal is to exercise more of it.

Does the brush create the painting?

AI helped me write this piece. I brought the idea and described the process. AI reflected it back and gave it an initial shape. I corrected the pathway when the shape was wrong. I asked for a different rhythm when the prose did not sound like me. I wrote the title. We made an outline together, and I changed it. AI drafted sentences; I read them, questioned them, cut them, and changed the direction.

So who wrote it?

If writing means physically formulating every sentence, then AI wrote a great deal of it. If writing means choosing the question, pursuing the answer, deciding what the evidence means, shaping the argument, and taking responsibility for the result, then I wrote it.

The honest answer is that we wrote it together, but collaboration doesn’t erase authorship. It asks us to think more carefully about where authorship lives.

Does the brush create the painting?

Leave a comment

Share

Anthralytic is a strategy and evaluation studio for mission-driven organizations. We help teams use data, evidence, and AI to understand what is working, make better decisions, and build systems that serve people—not the other way around.

The Census Bureau has proposed major changes to the rules governing the 2030 Census, and the public has until October 13, 2026 to respond. Because the comment period is brief, people and organizations that depend on accurate census data should review the proposal now.

The proposal raises four connected concerns. It would change which residents count toward congressional representation, create new risks for census participation, remove race and ethnicity questions from the decennial form and adopt a contested interpretation of the Fourteenth Amendment. Each change could shape political representation and public data for the following decade, which makes the public-comment process especially important.

Subscribe now

Changing who counts changes representation

The census currently counts people where they usually live, regardless of citizenship or immigration status. Including noncitizens does not give them voting rights. It reflects the number of people who live under a government’s authority, are represented by its elected officials and rely on its public institutions.

The proposed rule would count only U.S. citizens and lawful permanent residents toward congressional apportionment. Other foreign citizens would be excluded, including undocumented residents and many people who are lawfully present without green cards.

That change has political consequences because state population totals determine how the 435 seats in the House of Representatives are distributed, as well as each state’s number of Electoral College votes. Changing who is included in those totals can redistribute representation even before district boundaries are drawn.

A Pew Research Center analysis estimated that excluding unauthorized immigrants from projected 2020 totals could have shifted six House seats among six states. The analysis does not predict what will happen in 2030, and the actual distribution will depend on future population totals. It does, however, demonstrate how changing the apportionment population can move political power from one state to another. The current proposal is broader because it reaches beyond undocumented residents.

This is different from conventional gerrymandering, which involves drawing district boundaries. The connection is that both can affect representation. This proposal would do so by changing the population base used before the maps are drawn.

Fear can suppress participation

Federal law currently provides strong protections for census responses. Title 13 prohibits the Census Bureau from giving identifiable responses to immigration-enforcement agencies or using them for law-enforcement purposes.

Those protections matter, but they do not necessarily eliminate the fear that census participation could expose an individual or family member to immigration consequences. The proposal contemplates using records from the Department of Homeland Security and other agencies to classify residents by legal status. It also asks for public comment on whether to add a legal-status question to the census form.

For people in mixed-status households, the separation between statistical data collection and immigration enforcement may not feel secure. Some may avoid the census, leave family members off the form or provide incomplete information.

Census Bureau studies have produced mixed findings about the overall effect of a citizenship question. A 2019 randomized test found no statistically significant difference in overall self-response, although it identified lower response among some groups and in some areas. More recent Census Bureau research found that sensitivity varied significantly among households and that response fell most among households containing noncitizens who were ineligible for Social Security numbers.

This risk matters because an undercount would affect citizens and noncitizens alike. Census totals support population estimates, public-funding decisions, schools, hospitals, transportation, emergency planning and research. If fear causes particular populations to be missed, the resulting errors can influence public decisions for ten years.

Removing race and ethnicity questions would hide disparities

The proposal would prohibit race and ethnicity questions on the decennial census form. This change deserves its own discussion because it would affect how the country identifies and measures differences among communities.

The American Community Survey could continue collecting race and ethnicity information, but it is based on a sample rather than a complete count. Its estimates become less precise for smaller populations and geographic areas, while administrative records are not an equivalent replacement for direct self-identification.

Race and ethnicity data make it possible to disaggregate population totals. Without that detail, an overall number may appear reasonable while concealing substantial differences among the populations included within it.

I have seen this repeatedly in my work and have written before about why disaggregation is essential to understanding what works. Aggregate data can make a program appear effective while obscuring who benefited, who did not and why. When information is no longer available by race or ethnicity, disparities can disappear from the analysis even though they remain present in people’s lives.

Disaggregated census data support voting-rights enforcement, fair-housing work, public-health analysis, resource allocation and efforts to determine which populations were missed by the count. Removing race and ethnicity questions from the complete census would weaken a basic source of evidence used to understand unequal representation and outcomes.

The Fourteenth Amendment says persons

The constitutional question is direct. Section 2 of the Fourteenth Amendment requires representatives to be apportioned according to the “whole number of persons in each State.” The text does not say citizens, voters or lawful permanent residents.

The administration argues that some immigrants lack the allegiance or durable connection needed to qualify as usual residents. Under that interpretation, citizenship or permanent legal status can help determine whether someone should be included in the apportionment population.

The opposing interpretation emphasizes the amendment’s use of the word “persons,” along with the long history of including resident noncitizens in the apportionment count. From this perspective, immigration status is distinct from the question of whether someone actually lives in a state.

The resulting legal question is whether the executive branch can narrow the population included under the phrase “whole number of persons” by changing its definition of usual residence. Courts may ultimately address that question, but uncertainty surrounding the rule could affect public trust and census participation before litigation is resolved.

Submit a public comment

Public comments are due October 13, 2026.

A comment does not need to be long or written by a lawyer. It can explain which parts of the proposal concern you, why accurate and disaggregated census data matter to your community or work and what you want the Census Bureau to do.

Comments may ask the Bureau to:

• Continue counting residents based on where they usually live, regardless of immigration status.

• Preserve race and ethnicity questions on the decennial census.

• Decline to add a citizenship or legal-status question.

• Publish evidence about the accuracy and limitations of the administrative records it plans to use.

• Extend the public-comment period and conduct broader consultation.

Submit a comment through Regulations.gov.

These changes are still proposals. Public comment is the opportunity to tell the Census Bureau, on the record, who should be included in the count and which information the country needs to preserve.

Anthralytic helps mission-driven organizations use evidence, context and human insight to understand what works, for whom and why. Subscribe for clear analysis of data, evaluation, power and the decisions that shape public life.

Share

Legacy Investing withdrew its land-use application for the former Minnesota Star Tribune printing plant and terminated its agreement to purchase the property. The proposed 20-megawatt data center, at least for now, is dead.

I would love to tell you exactly why. I cannot.

Legacy has not publicly explained its decision, and there is no evidence that allows us to say neighborhood opposition killed the project. What we know is that hundreds of people showed up when the proposal was presented publicly in August, many of them strongly opposed. We know the developer had not yet provided the site-specific information people were asking for about electricity, water, noise and other impacts. And we know that, rather than continue through that process, Legacy withdrew its application and its purchase agreement.

In my last piece, I argued that Minneapolis should not say yes until Legacy came back with what I called “the meter, the model and the commitments”: actual resource-use numbers, evidence about impacts and binding promises that could survive a tenant change, expansion or sale.

Legacy never came back with them.

That might sound like the end of the story.

It isn’t.

Minneapolis Kept Going

The data center disappeared. The policy problem did not.

Minneapolis is still developing permanent rules for data centers, and the latest proposal gets surprisingly close to some of the questions I raised in my first piece.

Under the city’s preliminary recommendations, every new or expanded data center would require a conditional-use permit and public hearing. Applicants would have to disclose projected water and electricity use, generator use and plans for controlling sound. They would also have to provide written evidence that they have coordinated with the electric utility.

The city is also proposing something more fundamental: deciding where data centers belong before another developer arrives.

Under the current proposal, new data centers would be limited to downtown zoning districts and placed in buildings that already exist. Downtown server and equipment space would be capped at 175,000 square feet. New purpose-built data center buildings would not be allowed, and data centers established after January 1, 2026 could not be the only principal use on a downtown property.

These rules are not final. The Planning Commission is tentatively scheduled to consider them October 13, followed by City Council consideration in November.

But the direction matters.

Instead of waiting for another proposal and then scrambling to figure out what questions to ask, Minneapolis is beginning to establish the questions in advance. I think that is a much better way to govern infrastructure.

Minnesota Is Asking Who Pays

The state is doing something similar from a different direction.

One of the biggest questions in my previous piece was deceptively simple: if a data center requires new electrical infrastructure, who pays for it?

Minnesota has begun answering that.

State law now requires special treatment of very large electricity customers, and the Minnesota Public Utilities Commission has established a framework intended to keep the costs of serving them from being shifted onto existing households and businesses.

The principle is straightforward: if a data center requires electrical system upgrades and additional infrastructure, the data center should pay the costs attributable to serving it. Utilities must develop special rates for very large customers, and the PUC reviews the agreements governing how those customers are served.

That sounds obvious.

It isn’t how infrastructure costs necessarily work without regulation.

A utility may need to build substations, transmission lines or other equipment based on enormous projected electricity demand. If the customer later scales back, delays construction or disappears entirely, someone can still be left paying for the infrastructure.

That creates another problem regulators are beginning to confront: what happens when the demand itself is speculative?

And Minnesota is no longer dealing with hypothetical projects. The Public Utility Commission (PUC) is reviewing electric-service agreements associated with proposed large data centers, including Google’s planned Hermantown project.

The question has moved beyond whether Minnesota wants data centers.

It is becoming: On what terms?

This Is Becoming a National Question

Minnesota is hardly alone.

In 2026, lawmakers in 16 states introduced or considered legislation that would pause or restrict new data-center development, according to the National Conference of State Legislatures. Some proposals remain active, while others have failed or been vetoed. The stated rationale varies, but many proposals are intended to give governments time to understand effects on electric grids, communities and public resources before additional projects are approved.

Other jurisdictions are trying to regulate rather than pause.

New York has proposed requiring developers of new data centers to make community investments of at least $1 million for every megawatt of utility demand. Massachusetts is requiring large data centers seeking state permits to negotiate community-benefit agreements. Columbus is considering special utility rates for large industrial users along with water conservation, public disclosure and decommissioning requirements.

And this week the issue reached Congress.

On September 16, the U.S. House passed the Ratepayer Protection Act 417 to 3. The legislation directs state utility regulators to address whether data centers and other very large electricity users are paying the costs of the new generation and transmission infrastructure needed to serve them. Critics argue the legislation does not go far enough, but a 417-to-3 vote tells us something about how far this issue has moved into mainstream public policy.

Meanwhile, resistance is growing in communities from Silicon Valley to Texas, New York and the Midwest. The arguments are remarkably similar: electricity, water, noise, pollution, tax subsidies, relatively limited permanent employment and a basic question about whether communities are receiving enough in return for the resources these facilities consume.

A year ago, much of the conversation about AI infrastructure centered on how quickly we could build it.

Now another question is catching up:

Who carries the consequences after it is built?

Approval Is Not the Finish Line

We tend to treat infrastructure decisions as approval decisions. A developer proposes something. Government studies it. Residents comment. Regulators impose conditions. Somebody eventually says yes or no. But approval is only one moment in a system that may operate for decades.

The questions being asked now are largely questions of governance. Who pays for new infrastructure? What limits are placed on expansion? What happens when a tenant changes? What information must be disclosed? Who is responsible for decommissioning, and what obligations survive a sale? These are decisions about the rules under which a data center is allowed to operate and who carries the risk when things do not go according to plan.

Then comes another set of questions that interests me as an evaluator: Did what we were promised actually happen? Did electricity and water consumption stay within projections? Did the developer, rather than existing ratepayers, actually bear the costs attributed to the project? Did promised jobs, tax revenue and community investments materialize? Did noise and emissions remain within agreed limits? Did the benefits reach the people they were supposed to reach? And when actual performance diverged from the projections used to secure approval, did anything happen as a result?

That is where evaluation belongs. A projected water-use number is a prediction, not an outcome. A community-benefit agreement is a promise, not evidence of community benefit. And a ratepayer protection does not, by its existence, tell us whether ratepayers were actually protected. We need to follow these projects long enough to compare what was promised with what happened, understand who benefited and who bore the costs, and identify consequences nobody anticipated when the deal was approved.

If data centers are becoming essential infrastructure, we need both sides of this equation: stronger governance before they are built and meaningful evaluation after they begin operating. The ribbon cutting should not be the moment when public scrutiny ends.

There Are Still Harder Questions

There is a danger, though, in telling this story as communities finally standing up to Big Tech because somebody has to host this infrastructure.

I wrote this before and I think it matters even more now: putting a data center somewhere else does not make its impacts disappear.

If affluent neighborhoods with political influence become very good at stopping data centers, developers will look elsewhere. That could mean rural communities with smaller tax bases, places hungry for investment, communities with weaker regulatory capacity or areas where residents have less time and money to organize.

We could congratulate ourselves for protecting one neighborhood while simply exporting the electricity demand, water consumption, generator emissions and land-use consequences somewhere with less power to resist them.

That is not responsible infrastructure policy.

There is another tension too. Communities can demand so much compensation that community benefits start looking like a price for accepting harm rather than a strategy for preventing it.

New York’s proposed $1 million-per-megawatt community investment is an interesting experiment. A 100-megawatt facility would imply at least $100 million in community investment. That is real money. But money does not make every site appropriate.

A community-benefit agreement cannot manufacture water in a stressed watershed. Tax revenue cannot make an overloaded transmission system reliable. A new park doesn’t cancel out continuous noise next door. Compensation should address impacts that remain after good siting and mitigation, not become permission to ignore them.

And there is a final tension that makes me uncomfortable because I am part of it.

Demand is coming from us.

I use AI heavily. Businesses are embedding it into their operations. Governments are adopting it. People stream more, store more and compute more. AI agents may dramatically increase the amount of computing happening behind a single human request.

We cannot demand infinite digital infrastructure and simultaneously insist that none of its physical infrastructure exist near anyone. But neither should technological demand become a blank check.

Six days after I asked whether one Minneapolis data center could meet that standard, its developer walked away. We still do not know why. The more important development may be what remained after it left.

Minneapolis kept writing rules. Minnesota kept building ratepayer protections. Other states and cities kept experimenting with moratoriums, community-benefit agreements, disclosure requirements, special utility rates and decommissioning plans. Congress took up the question of who should pay for the infrastructure these facilities require.

The conversation is beginning to move beyond whether a data center should receive permission to exist. It is moving toward something harder and more useful:

What did you promise?

What actually happened?

Who benefited?

Who paid?

And what are we going to do if the answers are not the ones we were given?

That is the accountability infrastructure we need to build alongside the data centers themselves.

Leave a comment

Share

Anthralytic explores AI, data, evaluation and the systems shaping social impact. We look past both hype and reflexive rejection to ask what the evidence shows, who benefits, who bears the costs and how we build accountability into the systems we create.

I want to be honest and transparent about my own position: I use AI. Probably heavily.

I use it to make my work more efficient and effective and, I hope, to produce work that benefits people. Like most of us, I also depend on the internet throughout my work and daily life. I store documents in the cloud. I stream music and video. I buy things online. I search, scroll, message and share. I try to make sustainable choices, but our work and lives have been organized around digital systems in ways that make simply opting out extraordinarily difficult.

All of that does happen in the cloud. But the cloud is not weightless or placeless. It is a service built on physical infrastructure.

Every prompt, search, shared document and streamed video is processed or stored somewhere in a physical building filled with servers, cooling equipment, electrical connections and backup generators. The internet has a body. It takes up land. It draws power. It produces heat. Sometimes it consumes water. It lives somewhere.

Now, someone wants it to live in my backyard.

Legacy Investing is an Arlington, Virginia-based real estate investment and development firm with a dedicated data-center business, Legacy Data Centers. It develops and repositions properties for enterprise, cloud and AI computing tenants. In this proposal, Legacy is the prospective buyer and developer, not the still-unidentified company that would ultimately occupy the facility and run the servers. That distinction matters because the developer can make commitments about the building, but many of the facility’s eventual energy and environmental impacts will depend on the tenant and its computing workloads.

Legacy has entered into an agreement to purchase the former Minnesota Star Tribune printing facility at 800 North First Street, a roughly 13-acre site in Minneapolis’s North Loop. The company wants to convert the enormous press building into a data center and describes the project as part of a broader mixed-use redevelopment.

The proposed data center would be “around 20 megawatts initially,” according to an interview the developer gave the North Loop Neighborhood Association.

That sentence contains a word doing a lot of work: initially.

Twenty megawatts of continuous demand would equal about 175 gigawatt-hours of electricity in a year. That is not a forecast of what the facility will actually consume; we do not yet know whether the 20 MW refers to the servers, the whole building, the interconnection capacity or only a first phase. But that is exactly why the qualification matters. “Initially 20 MW” could eventually mean 30 MW, 50 MW or something larger unless the approval establishes a real ceiling.

I have written before about AI’s environmental footprint, including the possibility that AI could help reduce its own energy and resource use. At the time, I was writing about a global system. This proposal has forced me to ask what those arguments mean at the scale of a neighborhood. My neighborhood.

It is easy to oppose a data center in the abstract. It is also easy to praise one in a press release. It is much harder to decide whether this particular facility, on this particular site, under these particular conditions, would produce more public value than public cost.

That is the work we need to do now.

Watch the Meeting

Before deciding what you think, I recommend watching the recording of the August 19 North Loop Planning + Zoning meeting.

The meeting is important partly because of what did not happen. The committee did not endorse the proposal. It did not reject it either. It took no action because Legacy’s representatives were prepared to discuss data centers generally but could not yet provide the site-specific information committee members wanted about electricity, water, noise and other impacts. The committee requested more time.

That distinction matters. Unanswered questions are not evidence that a project is harmful. They are also not a basis for approving it.

Legacy has offered a plausible case for the site. Printing plants have strong floors, high ceilings, large open spaces and substantial infrastructure. The company says it expects to use closed-loop and air-cooling technology with very little water. It says generators can be placed inside the building and acoustically managed. It says existing power infrastructure can serve the project without adding new strain to the grid. It says other conversions of the press building would be financially difficult and that surrounding parcels could support community-oriented or mixed uses.

Each of those statements could be true.

But at the meeting, they remained statements. The engineering plans, utility analysis, enforceable limits and financial commitments needed to test them were not available. We were being asked to evaluate the shape of a project by looking at the blank spaces around it.

The Two Easy Answers

The first easy answer is: No way.

Data centers use too much electricity. They can consume water, produce noise and generator emissions, create relatively few permanent jobs, receive public subsidies and lock valuable land into a highly specialized use. Put the words “AI data center” next to a neighborhood and opposition now arrives almost automatically.

The second easy answer is: Why would we turn this down?

The building is vacant. Its former use is gone. A data center could restore taxable value, generate construction activity, reuse an industrial structure and contribute electricity franchise fees to the city. Minneapolis has a budget problem and a weakened commercial tax base. Why refuse an investor willing to put an obsolete building back to work?

Mayor Jacob Frey is trying to occupy the space between those positions. He has said data centers need regulation to protect livability, health and safety, but also argues they could help lower the tax burden on everyone else. He does not want a data center to be the only use on the property; he wants something the neighborhood can use too, such as restaurant or event space.

That argument requires some context. Frey is not an outside observer of the city’s tax burden. Under Minneapolis’s current government structure, city departments report to the mayor. The mayor proposes the budget, the City Council amends and adopts it, and the mayor approves the result. Frey therefore did not create the city’s fiscal problem alone, but his administration has helped make the spending, staffing and budgeting decisions that produced it.

For 2027, Frey has proposed an 11.3 percent increase in the city’s property-tax levy and the elimination of roughly 100 positions to address a budget problem of more than $60 million. The gap reflects inflation, rising labor and operating costs, the end of federal pandemic relief, declining downtown property values and repeatedly underbudgeted police overtime. Operation Metro Surge added to the pressure, costing the city more than $6 million in one month, but it did not create the entire structural problem.

Frey did not create the tax burden alone: the mayor proposes the budget and oversees city departments, while the City Council amends and adopts it. But he is not an outside observer either. City leaders helped create the imbalance residents are now being asked to correct. That makes the prospect of new tax revenue relevant, but the city’s need for money does not establish that this particular project provides a net public benefit.

How much net tax revenue would this project produce after exemptions and public costs? Would the surrounding development actually be built? Who would pay for any grid upgrades? What happens if the tenant leaves? What does “minimal” water use mean in gallons, during both average operations and the hottest week of the year?

The economic benefit cannot simply be assumed because the building would become more valuable. The environmental harm cannot simply be assumed because it would contain servers. Both have to be demonstrated.

We Cannot Say No to All of Them

This is where my own AI use matters.

It would be incoherent for me to demand the benefits of AI and the internet while insisting that every community refuse the infrastructure that makes them possible. Even people who never touch ChatGPT depend on data centers for medical records, banking, emergency services, government systems, logistics, communications and ordinary websites.

We need data centers.

But needing data centers collectively is not the same as needing every proposed data center, at every proposed size, in every proposed location, on whatever terms its developer offers.

Necessity should give the public more bargaining power, not less. If data centers are becoming essential infrastructure, we should plan them with the seriousness we apply to other essential infrastructure. We should decide where they fit, what capacity a place can support, who pays for the supporting systems and which obligations will remain after the current developer or tenant is gone.

The question is not whether data centers should exist.

The question is: Where should they go, where should they not go, and what does a responsible yes require?

Where Should Data Centers Go?

There is no impact-free location. Moving a data center out of an affluent urban neighborhood does not make its power, water and land requirements disappear. It may only move them to a rural community with a smaller utility rate base, a stressed aquifer, valuable farmland or less political power.

“Put it somewhere else” is not an infrastructure policy.

At the same time, not every empty building or industrial parcel is a good data-center site. Research from the U.S. Department of Energy’s Lawrence Berkeley National Laboratory shows that the same digital work can carry very different water and carbon consequences depending on where and how it is performed. Location is not a secondary question to be addressed after a deal is announced. It is part of the environmental technology of the facility.

I’ve been going down a rabbit hole the past day reading about this and I’ve found that a good site begins with several things, the first being grid fit. It has demonstrable electrical capacity or a credible plan for adding capacity without shifting upgrade costs and stranded assets to households and other businesses. The facility can reduce or curtail demand during grid stress, add genuinely new clean generation and match its consumption to clean power in the place and hours where it operates, rather than just buying annual renewable credits from somewhere else.

It also has water fit. The cooling design matches the local watershed and climate. It uses little or no potable water where supplies are constrained, and its water claims include both direct cooling and the water associated with electricity generation. A facility that is efficient in carbon terms can still be badly located in water terms. There is no single sustainability number that resolves every tradeoff.

Then there is land fit. Existing industrial buildings, brownfields and retired power sites may offer reusable structures, transmission equipment and lower-conflict land. But “industrial” is not a magic word. Cities should still ask what else the site could become and what the community gives up by dedicating it to servers for decades.

There is neighborhood fit. Cooling equipment, transformers and generators have to coexist with the people already there. Distance, building design and enforceable property-line limits matter. A facility should not go where it can meet its operational needs only by asking nearby residents, schools or hospitals to absorb continuous noise or episodic pollution.

Finally, there is governance fit. A responsible site is in a jurisdiction willing and able to require public data, enforce limits, inspect operations and respond when the facility changes. A community should never be selected because its rules are weak or because its residents have less capacity to resist.

The simplest version is this:

A data center should not go anywhere it can operate only by externalizing its costs.

It should not depend on residents financing its electrical infrastructure, another community supplying its clean energy, a stressed watershed absorbing its cooling demand, or promises of future development substituting for binding commitments now.

Does the North Loop Site Fit?

The honest answer is that it has some characteristics of a good site and several unresolved warning signs.

Reusing the former printing plant could be a real benefit. It is an unusually large, specialized industrial building that may be difficult to convert to housing or ordinary commercial space. Preserving and adapting it may avoid some of the material and carbon costs of demolition and new construction. If existing electrical and structural infrastructure can genuinely be reused, that matters too.

The site is also not an isolated industrial campus. It sits within the North Loop, a growing neighborhood where people live, walk, work, eat and gather. The property is large enough that its use will shape this part of Minneapolis for decades. That raises the standard for noise control, street-level activity, urban design and the promised mixed-use component.

Most importantly, the core claims have not yet been substantiated publicly.

“Existing infrastructure” is not the same as a completed utility study showing available capacity, required upgrades, cost allocation and effects on reliability. “Closed-loop cooling” is not a water budget. “Generators inside” is not a noise and emissions analysis. “Mixed use” is not a construction schedule, financing plan or recorded obligation.

And “initially 20 MW” is not a maximum.

Minnesota’s Environmental Quality Board says connected and phased actions should be considered together in environmental review, including expansions that are planned or reasonably likely. Minneapolis should evaluate the facility the building and infrastructure are capable of supporting, not only the first equipment installed.

That question is especially urgent because the city is in the middle of rewriting its data-center rules. Its preliminary recommendations would require a conditional-use permit, disclosure of projected water and electricity use, evidence of utility coordination, restrictions on equipment placement and a rule that new downtown data centers cannot be the only principal use on a property.

But according to the timeline provided by the North Loop Neighborhood Association, this application may be decided under the current, less specific rules if it is deemed complete before the new regulations take effect. If that happens, the conditions attached to this particular approval become even more important.

Can AI Reduce the Footprint of AI?

Here is the hopeful part: yes, it can.

Machine learning can analyze temperatures, pump speeds, weather, server loads and thousands of sensor readings to operate cooling systems more efficiently than static rules. In 2016, Google reported that its DeepMind system reduced cooling energy by as much as 40 percent, equivalent to about a 15 percent reduction in the facility’s overall non-computing energy overhead.

That distinction is important. It was not a 40 percent reduction in the total electricity used by the data center. It was a large improvement in one part of the system.

AI can also forecast equipment failure, consolidate workloads onto fewer machines, schedule flexible computing for cleaner hours and coordinate increasingly complex combinations of air and liquid cooling. A 2025 systematic review in Applied Energy identified 65 studies using reinforcement learning to improve cooling, workload scheduling, resource allocation and other data-center operations. The body of research is promising, although much of it still depends on models, simulations or facility-specific experiments rather than transparent, long-term public results.

Cooling technology itself is improving. A 2025 life-cycle assessment published in Nature found that advanced cold-plate and immersion systems could reduce energy demand, greenhouse-gas emissions and blue-water consumption compared with conventional air cooling. But the study also illustrates why we need life-cycle analysis: a technology that looks efficient at the server can carry different material, chemical or end-of-life consequences elsewhere.

So yes, AI can help shrink a data center’s footprint.

What it cannot do is make unlimited growth sustainable.

The International Energy Agency reported in 2026 that electricity used per AI task is falling rapidly, while total data-center electricity demand is still on track to double by 2030. Efficiency makes each unit of computing cheaper. Cheaper computing encourages more use. AI agents may perform hundreds or thousands of operations where a person once made one request. The denominator improves while the total keeps rising.

This is why an efficiency ratio is not an environmental limit. If both figures describe total facility demand, a data center operating at 50 MW draws exactly 30 MW more power than one operating at 20 MW, or two and a half times as much. If both ran continuously at those levels for a year, the difference would be 262.8 gigawatt-hours. The larger facility may perform more computations per unit of electricity. It still consumes more electricity overall.

It is also why we need to know who controls what. The building operator controls much of the cooling and physical infrastructure. The tenant controls the chips, models and workload scheduling. The utility controls much of the power supply. With no tenant identified, Legacy cannot yet tell the public whether workloads will shift to cleaner hours, which hardware will be installed, how heavily it will run or whether AI will actually be used to optimize operations.

The right questions are concrete:

• Will this facility use AI-managed cooling, or is that merely possible in the industry?

• What Power Usage Effectiveness and Water Usage Effectiveness will it guarantee?

• Will it report total electricity and water consumption, not just efficiency ratios?

• Can its workloads respond to grid stress?

• Will its clean-energy purchases add power to the local grid and match consumption hourly?

• Who verifies the results?

“AI can reduce the footprint” is a reason to set a higher performance standard. It is not a reason to assume the standard will be met.

Follow the Power, the Water and the Money

The immediate effects of a data center can be measured. Minneapolis should insist on measuring them before and after approval.

For power, we need the expected average and peak demand, the hard maximum demand, the proposed ramp-up schedule and the upgrades necessary to serve it. Minnesota’s Public Utilities Commission describes its role as protecting reliability and preventing the costs of serving large data centers from being shifted to other customers. But aggregate promises are not enough. The public needs to know how those protections apply to this project and what happens if the customer leaves before the infrastructure is paid off.

For water, we need annual and peak-day consumption, the source, the cooling technology and the conditions under which the system might change. A design that uses little water today should not be allowed to add evaporative cooling later without new review.

For noise and air, we need the number, size and location of generators; their fuel; their testing schedule; their expected operating hours; their exhaust controls; and measured noise limits at the property line. Equipment being indoors may help. It does not remove the need for evidence.

For money, we need a net fiscal analysis rather than a gross property-value claim. A data center may contribute substantial property taxes, electricity franchise fees and construction spending. It may also receive exemptions and create far fewer permanent jobs after construction ends.

Minnesota’s own evaluation of the state data-center equipment tax exemption is a useful warning against assuming that every large capital investment pays for itself. Looking across the state’s experience rather than this particular project, the report estimated approximately $0.98 in value-added impact for every dollar of forgone revenue, compared with $1.19 if the state collected and spent that dollar on public services. The report also found that the largest employment effects occur during the two-to-three-year construction period.

That does not prove the North Loop project is uneconomic. It proves that the benefit has to be calculated rather than declared.

And then there is the hardest cost to quantify: what this site will not become. A data center might be the most financially feasible reuse of the printing building. It does not follow that it is the best use of the entire property. The surrounding parcels, the street edge and the connection between the neighborhood and the river-adjacent industrial district all carry opportunity costs. “Mixed use someday” is not enough to resolve them.

Promises Need Longer Lives Than Press Releases

The facility Minneapolis approves today may not be the facility operating ten years from now.

The initial 20 MW may become 30 or 50. A cloud tenant may be replaced by a more energy-intensive AI tenant. A dry-cooled facility may add evaporative cooling. Promised housing, retail, public space or event uses may be delayed after the data center is operating. The property may be sold. Improved efficiency may lead to greater utilization. Grid investments may become stranded if the tenant leaves. A capital-intensive data-center conversion may determine the site’s character long after today’s officials and developers have moved on.

A responsible yes has to mitigate every one of those possibilities.

That means a hard cap on both total facility demand and IT load, with a new public review before either increases. It means a binding water ceiling and a prohibition on materially changing the cooling system without approval. It means publicly enforceable noise, generator and emissions limits. It means treating a major change in tenant or workload as a potential change in impact, not merely a private leasing decision.

If mixed-use development is part of the public-benefit case, its milestones should be tied to the data center’s power ramp or occupancy. The profitable component should not be completed first while the community component remains perpetually conceptual. Performance bonds or other financial security should back the promise.

The obligations should run with the land so they survive a sale. The utility agreement should protect other customers against upgrade and stranded costs. The project should carry decommissioning security so the public is not left with specialized infrastructure and an empty shell if the market changes.

And the facility should report what it actually uses, not only what it projected in its application. At minimum, annual public reporting should cover electricity, peak demand, water, carbon intensity, generator hours and fuel, property-line noise, efficiency metrics, tax payments, exemptions and progress on the mixed-use commitments. Independent audits should verify the numbers.

Some commercially sensitive information can remain private. Aggregate environmental performance cannot. A community cannot enforce a promise it is not allowed to measure.

My Answer, For Now

I am not asking Minneapolis to reject the infrastructure that makes my own work possible.

I am asking the city to decide where that infrastructure belongs and under what conditions, using evidence rather than fear or promises. This site may prove suitable. Reusing the press building may be smarter than demolishing it. A carefully designed data center may add revenue without imposing unacceptable costs. AI may help make it meaningfully more efficient.

But may is not the same as will.

Based on the information available now, I do not think there is enough evidence to approve the proposal. I also do not think there is enough evidence to declare that no responsible version of it could work.

Before a yes, Minneapolis should have:

• A complete site-specific power, water, cooling, noise and generator plan.

• Independent confirmation of grid capacity, upgrade costs and ratepayer protections.

• A hard maximum size, with reasonably foreseeable expansion reviewed as part of the project.

• A net fiscal analysis that accounts for incentives, public costs, jobs and alternative uses.

• Binding deadlines and financial guarantees for the promised mixed-use development.

• Actual public performance reporting and independent verification.

• Conditions that survive a tenant change, cooling change, ownership change or closure.

If the developer can meet those conditions, the conversation should continue. If it cannot, Minneapolis should say no. Not because data centers are categorically bad, but because this one would be asking the public to accept risks the applicant is unwilling to measure or carry.

My use of AI does not disqualify me from asking these questions. It implicates me in them.

We do not get the cloud without the ground beneath it. We do not get frictionless digital services without physical costs landing in real communities. The answer cannot be to hide those costs somewhere with fewer resources or less power to object. It also cannot be to approve whatever arrives because the internet has become indispensable.

We need to learn how to say yes well.

“No data centers anywhere” is not a serious answer to a society that depends on them. “Trust us” is not a serious answer to the communities being asked to host them.

The work lies between those positions: identifying the places where the costs are lowest, the public benefits are real and the remaining risks can be bound tightly enough to survive the next expansion, the next tenant and the next sale.

We cannot say no to every data center.

We cannot say yes to a blank check.

Right now, Minneapolis should ask Legacy to come back with the meter, the model and the commitments, then refuse to call it a yes until all three are real.

Anthralytic examines AI, data, sustainability and the human consequences of technological change. I look beyond both hype and reflexive rejection to ask what the evidence actually shows, who benefits, who bears the costs and what responsible progress could look like. Subscribe to join me in making sense of the systems shaping our lives.

Most people will never choose, configure, or directly interact with these systems. Their agency comes from the structures surrounding them: professional standards, public records, oversight, independent evidence, appeals, and carefully defined opportunities to participate.

This is what makes the public position different. Public agency is mostly institutional. The challenge is building institutions capable of matching the strength of their governance to the scale of AI’s consequences.

This is also the final position in this series. I’ve written about being the user, the subject, the source, and the worker. Each position offers at least some opportunity for individual action. The public position asks a different question: What must the institutions acting on our behalf be able to do?

Public agency lives in institutions

We delegate decisions all the time. Elected officials set policy. Public employees administer programs. Teachers choose instructional methods. Doctors exercise professional judgment. Procurement teams negotiate contracts.

That delegation is necessary. A functioning society can’t ask every person to participate in every operational decision. Public agency doesn’t require constant public involvement. It requires institutions that use their delegated authority competently, transparently, and within appropriate limits.

AI complicates that work because a system that appears to be a routine tool can quietly change how an institution sees and acts on the world. It can influence which cases receive attention, which patterns become visible, which risks matter, and which people have to work harder to be understood. It can also create real benefits by helping institutions find information, reduce delays, identify unmet needs, and deliver services more consistently.

The task is to distinguish between a bounded use of technology and a decision that changes public conditions.

That distinction should determine the level of governance.

NIST provides an operating structure

The NIST AI Risk Management Framework is one of the foundations of the AI safety framework I’ve been developing for Anthralytic. I keep returning to it because it’s an ongoing organizational practice rather than a verdict about whether AI is good or bad.

NIST organizes that practice into four functions: Govern, Map, Measure, and Manage.

Govern establishes responsibility and the institution’s approach to risk. Map examines the purpose, setting, people, and possible effects of a particular system. Measure tests performance and makes impacts visible. Manage turns the evidence into decisions.

These functions are connected. An institution can’t measure the right things if it hasn’t understood the context. It can’t manage a risk if nobody has the authority to act on the findings. It can’t govern responsibly if it treats the original purchase as the end of the decision.

This structure also gives public participation a clearer role. Participation isn’t a universal requirement applied in the same way to every system. It’s one way institutions gain knowledge, test their assumptions, represent affected interests, and establish the legitimacy of consequential decisions.

The form and strength of that participation should follow from the risk.

Govern: Set the thresholds before the pressure arrives

Governance begins before a specific vendor or product is under consideration. An institution needs to decide who is accountable for AI, what evidence is required, which uses need additional approval, and how much risk it’s willing to accept.

Without those thresholds, every decision becomes an improvisation. Low-risk tools can become trapped in unnecessary bureaucracy, while consequential systems may move forward because nobody has been assigned the authority to slow them down.

A useful governance policy creates a graduated path. Bounded internal tools can move through an ordinary review. Public-facing tools require testing, transparency, and feedback. Systems with significant consequences require more independent evidence, broader representation, stronger approval, and ongoing oversight.

The exact categories will differ by institution, but the triggers should be established in advance. A hospital, school district, police department, foundation, and workforce agency operate in different environments. Their risk thresholds should reflect the authority they hold, the populations they serve, and the consequences of getting something wrong.

Good governance makes those differences explicit.

Map: Understand the public consequences

NIST’s Map function asks organizations to understand the system’s intended purpose, setting, expected benefits, limitations, and potential effects on individuals, communities, organizations, society, and the planet. Its AI RMF Playbook also encourages collaboration with external groups when they can help identify risks, alternatives, and acceptable boundaries.

This is where an institution determines what kind of decision it’s actually making.

Six characteristics are especially useful: consequence, reach, choice, reversibility, distribution, and uncertainty.

Consequence concerns what the system can change. A tool that helps draft an internal document is different from one that influences eligibility, employment, education, health care, safety, or liberty.

Reach concerns how widely the effects travel. A voluntary tool used by a small team has a different public footprint from a system operating across an entire school district, benefits program, or transportation network.

Choice asks whether people can realistically avoid the system. An opt-out isn’t especially meaningful when declining also means losing access to a job, public service, or essential opportunity.

Reversibility considers what happens after a mistake. Can the error be detected and corrected? Can the original decision be restored? Is there someone with the authority to repair the harm?

Distribution looks at where the benefits and burdens land. A system may save staff time while shifting work to residents. It may improve service overall while producing more costly errors for people with disabilities, limited English, or unusual circumstances.

Uncertainty concerns how much the institution actually knows. A familiar technology with years of evidence calls for a different approach from a novel system whose capabilities, data practices, or performance may change rapidly.

These characteristics aren’t a formula that produces an automatic answer. They help the institution see when a technical decision has acquired a public dimension. As the consequences, reach, lack of choice, difficulty of repair, unequal distribution, and uncertainty increase, so should the strength of the governance surrounding the system.

Measure: Treat experience as evidence

Institutions often evaluate technology through technical performance, cost savings, staff time, or vendor demonstrations. Those measures matter, but they rarely capture the whole public experience.

A chatbot may produce accurate answers in testing while confusing people who don’t already understand the program. A translation tool may perform well in widely spoken languages and poorly in the languages most needed in a particular community. A model may improve average processing time while creating long delays for the cases it can’t easily categorize.

NIST’s Measure function calls for testing in conditions similar to the actual deployment setting. It also includes feedback and appeals from users and impacted communities as part of evaluating system performance.

That’s an important shift. A complaint isn’t only a customer-service issue. An appeal isn’t only an administrative burden. Both can reveal something the institution’s original measures failed to capture.

This is one of the clearest roles for participation. People who experience a system can identify effects that are invisible to its designers. Frontline workers know where the formal process and the real process diverge. Community organizations may recognize barriers or patterns that don’t appear in aggregate data. Domain experts can determine whether a technically impressive result is useful in practice.

Participation improves measurement when it brings necessary knowledge into the institution.

Manage: Make the evidence consequential

The final function is Manage. Once an institution has mapped the context and measured the results, it has to decide what to do.

Sometimes the evidence will support broader adoption. Sometimes it will show that the system works only for a narrower use. The institution may need to change the interface, add human review, restrict access to certain data, improve an appeal process, renegotiate the contract, or conduct another pilot.

It may also need to stop.

The important thing is that the evidence can change the system. If a review can’t affect the scope, safeguards, resources, or decission to continue, then it’s documentation rather than governance.

Contracts matter here because an institution can manage only what it retains the authority to change. It may need access to audit records, notice of system updates, control over data retention, the ability to test vendor claims, and a workable way to export information or end the relationship. Those provisions are part of public governance because they preserve the institution’s ability to respond to what it learns.

Management also requires a schedule. A system should return for review when its purpose changes, new data is added, the vendor updates a model, evidence of harm emerges, or the original assumptions no longer hold. Higher-impact uses may need formal renewal dates so continuation becomes a decision rather than a default.

Participation needs a defined purpose

Public participation can contribute to each part of this process, but institutions should be clear about what people are being asked to influence.

Some participation helps establish context. Residents, workers, or service users may identify needs and barriers before a system is designed.

Some participation shapes implementation. People may influence accessibility, data practices, permitted uses, communication, or the design of an appeal process.

Some supports oversight. Affected groups may help interpret performance data, identify emerging harms, or recommend changes after deployment.

The most consequential uses may also require participation in authorization. That could include an oversight board, elected body, worker representatives, civil rights organizations, or a formal public process with the authority to set limits or reject a proposed use.

Timing determines what participation can accomplish. A public meeting held after a product has been selected may still improve implementation, but it can’t shape the selection itself. Institutions should be honest about which questions remain open and which decisions have already been made.

Public participation is meaningful when it can change the part of the decision it was convened to address.

Trust comes from capable institutions

Public trust doesn’t require consensus. People can review the same information and reach different conclusions about acceptable risk, appropriate spending, or the role of technology in public life.

Trust grows when people can see that an institution understood the decision it was making. There is a responsible owner. The expected benefit is clear. The affected groups and possible tradeoffs have been considered. Claims have been tested in the real setting. People can report problems and challenge outcomes. Someone has the authority to change course.

This is what the public position adds to AI safety. Individual agency still matters, but many of AI’s effects can’t be managed individually. We rely on institutions to recognize public consequences, draw on the right forms of knowledge and participation, and apply governance that is strong enough for the decision in front of them.

That question becomes especially tangible when AI arrives in physical form. A data center may begin as an economic development project or infrastructure agreement, but its public consequences can include land, electricity, water, tax policy, jobs, noise, emissions, and pressure on shared infrastructure. The scale and distribution of those effects make institutional governance especially important. Berkeley Lab’s research shows how quickly the electricity demands associated with data centers are growing.

That’s where I’m going next: the good, the bad, and the ugly of the data centers behind AI, and how AI itself might help reduce their footprint.

Leave a comment

Share

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

When I wrote Becoming a Cyborg Evaluator, I was excited about what happened when human judgment met machine capability. AI could hold more information than I could, find patterns across documents, translate technical language, and help me build tools that would once have required far more time and resources. It did not replace my judgment, but it extended my reach.

I still believe that. I use AI constantly, and Anthralytic would not exist without it. The Conditions Web is only one example of something I can build because these tools have expanded what is possible for a very small business.

What I did not ask clearly enough in that first piece was what happens to the work around the tool. Increased capability does not necessarily produce less work. Sometimes it simply expands the amount of work one person can imagine taking on.

That question becomes more important when the person using AI is not also the person deciding how the job is designed. A worker may choose how to write a prompt, but an employer determines the caseload, the performance target, the deadline, and what happens to any time the tool saves.

The technology changes the work. Power determines who benefits from the change.

There is more than one worker in the system

Because this series is about where people stand in relation to AI, it helps to distinguish three worker positions.

The first is the worker alongside AI, the person using it to write, analyze, code, summarize, translate, or complete administrative work. This is the position I know most directly, and it is where most conversations about productivity begin.

The second is the worker managed through AI. They may never enter a prompt, but software helps assign their schedule, track their activity, evaluate their performance, or recommend whether they should be promoted or disciplined. The OECD calls this algorithmic management, and its research shows that these systems are already common across the countries it studied. In this position, AI is not primarily a tool the worker controls. It is part of the institution looking back at them.

The third is the worker inside AI. Data labelers, content moderators, reviewers, and other workers prepare training data and correct the outputs that make an automated product appear automated. The International Labour Organization has called attention to these often overlooked data workers. Their labor is part of the system, even when the interface is designed to make the labor disappear.

These positions can overlap, but they do not carry the same power. A consultant choosing when to use a chatbot has more agency than an employee whose work is being scored by software, and both are positioned differently from a data labeler working through a platform they do not control.

This piece focuses mainly on the worker alongside AI because that is the position many of us are entering now. Even there, the central issue is not simply whether the tool works. It is who gets to decide what happens once it does.

Who owns the saved hour?

I asked a version of this question in Who Is Better Off When AI Speeds Up the Workflow?. A case manager who finishes documentation faster has produced a real efficiency gain, especially if documentation is the part of the job keeping them from being present with clients. The question is where the saved time goes.

It could become a longer conversation with a client, an actual lunch break, or a workday that ends on time. It could also become another intake, a larger caseload, a responsibility that used to belong to another position, or an hour spent checking whether the AI summary quietly changed something important.

AI does not choose among those outcomes. The workplace does.

The evidence so far does not tell a single story. A Zoom-commissioned survey found that 76 percent of AI users reported saving at least thirty minutes a day, and nearly three quarters said they would use the time for a dedicated lunch break. That is the hopeful version, and there is no reason to dismiss it. AI can give people time back.

An eight-month UC Berkeley Haas study found a different pattern. Workers at a technology company moved faster, attempted a wider range of tasks, kept multiple threads active, and allowed work to spread into times that had previously served as natural pauses. Nobody necessarily had to order them to do more. Greater capability widened their own sense of what they could take on, and that expansion gradually began to look like the new normal.

I recognize that pattern. AI allows me to attempt work that would previously have stayed on the someday list. That freedom is valuable, but it does not always make the list shorter. Often, it makes the list more ambitious.

The nonprofit sector adds another complication. People enter social impact work because they care, and that commitment can make additional capacity difficult to protect. If AI frees an hour, using it to serve one more person may feel like the obviously ethical choice. Do that often enough and the exceptional effort becomes the expected caseload. The worker remains just as tired, but the dashboard improves.

The work that does not disappear

The clean productivity story assumes that a task automated is a task removed. Sometimes that is true. More often, the work moves or changes shape.

Someone still has to prepare the information, decide what the system should do, check the output, correct errors, protect confidential material, explain the result, and accept responsibility when something goes wrong. A Workday survey of 3,200 employees found that nearly 40 percent of reported AI time savings was lost to correcting, rewriting, and verifying low-quality output. Workday sells workplace technology, so its research should be read with that interest in view, but the finding names a form of work that most productivity calculations leave out.

The reviewer is now expected to recognize an error they did not create, inside language polished enough to make the error difficult to see. In consequential work, that can require as much attention than producing the original result would have. The machine performs the first pass, while the human inherits the uncertainty and the liability.

This is why “a human remains in the loop” is not much of a safeguard by itself. The human needs enough time to review the work, enough knowledge to recognize a problem, and enough authority to reject the system’s answer. Without those conditions, human review becomes ceremonial. The person is present mainly so someone can be held responsible afterward.

There is also a slower question about skill. We do not need to preserve every repetitive task simply because doing it manually once taught us something. Calculators did not destroy mathematics, and spellcheck did not end writing. Still, workers need to retain the underlying skills required to judge whether the system is wrong. If someone can approve an AI-generated analysis but can no longer conduct or explain the analysis themselves, the organization has not eliminated risk. It has hidden dependence inside a faster workflow.

Start by finding out where the time went

The practical difficulty is that most organizations are not measuring any of this. They can see that more reports were produced or more cases were closed, but they cannot see whether the worker spent the saved time on higher-value work, AI cleanup, a larger workload, or recovery.

A worker can begin with a simple two-week time audit. This does not need to become another elaborate tracking system. At the end of each day, record which tasks involved AI, how much time the tool appeared to save, how much additional time went into prompting and verification, and what filled the remaining space. Also note whether the change improved the actual work, especially for the person the work was meant to serve.

The important part is not the precision of the minutes. It is the pattern. Did AI remove work, relocate it, or expand the job? Did it create time for judgment and relationships, or did it make the day denser? Did the worker finish earlier, or simply produce more before leaving at the same time?

If you are doing this for yourself, keep the record as a tool for understanding your own work and deciding what boundaries you need. If you manage people, be careful about asking employees to disclose time savings. To someone who reports to you, saying “AI saved me three hours” can sound like volunteering for three more hours of work. Any shared audit should be voluntary, anonymous where possible, and explicitly separated from performance evaluation.

Most importantly, do something with the answer. If time is being lost to correction, the organization may need a different tool, better training, or a workflow in which AI is used for fewer tasks. If the role has expanded permanently, the job description, staffing, and compensation should be reconsidered. If the tool has created genuine capacity, some of that gain should remain with the worker rather than being automatically converted into a higher target.

Renegotiate the work, not only the workflow

Organizations often introduce AI by redesigning the workflow while leaving the employment relationship untouched. The task changes, but responsibility, evaluation, compensation, and workload are expected to sort themselves out.

They rarely do.

Before adoption, a team should be able to write down what is changing, who will verify the output, what will happen to any time saved, which skills must remain human, what worker data the system will collect, how someone can challenge an AI-assisted assessment, and when the arrangement will be reviewed. This does not require a forty-page policy. It requires an honest agreement about the job.

Workers should also be involved before the tool is selected, not only trained after the decision has been made. The person doing the work often knows where automation would genuinely help, where it would add risk, and which apparently inefficient steps are carrying judgment or trust that the workflow diagram cannot see.

In Measuring the Wrong Thing Faster, I argued that the nonprofit sector often treats acceleration as impact because speed is what its dashboards can measure. A worker-centered assessment would look beyond volume. It would ask whether the job became more sustainable, whether workers retained meaningful judgment, whether the people served felt more understood, and whether the efficiency gain strengthened the mission rather than merely increasing throughput.

That does not make this an argument against AI. It is an argument for using AI well enough that the benefits reach the people doing the work. Saved time could become rest, flexibility, professional development, more thoughtful analysis, or the relational parts of a job that administrative work has crowded out. Those are productivity gains too, even when they do not appear as another completed unit.

I still want the cyborg version of work I imagined in that earlier piece, where machine capability extends human judgment rather than displacing it. I understand now that this outcome does not emerge automatically from having a good tool. It depends on how the work is governed and whether the worker has enough power to shape what happens next.

If AI saves an hour and the worker receives only a higher target, the technology did not give them time. It gave the institution more capacity.

When you are the worker, safety means having a voice in how the job changes, retaining the judgment necessary to challenge the system, and sharing in the value your AI-assisted labor creates.

Leave a comment

Share

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

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.