InquirySpec - Narrative Arc: Extend responsibility, alignment, and modeling beyond the individual human toward roles, groups, services, and institutions. - Paradigm Shift: The reader stops treating personhood as the only unit of analysis for agency-like behavior. - Reader Exit State: The reader can ask what entity is acting, through what interface, under what constraints, and with what accountability.

When the Entity Is Not a Person

We are trained to look for the person.

When something goes wrong, the first question is usually "Who did it?" That question has value. People make choices. People carry obligations. People can explain, apologize, escalate, repair, refuse, or repeat. A Field Guide about accountability cannot dissolve every action into a system and call that depth.

But personhood is not the only unit that acts in modern life.

A team can act. A role can act. A policy can act. A workflow can act. A service can act. A platform rule can act. A model output can act when people route decisions through it. An institution can act even when no single person experiences themselves as choosing the whole outcome. A field can act through shared incentives that make many local choices converge.

If we only know how to see individual people, we will misread these systems. We will assign an organizational failure to one worker. We will treat a software artifact as if it speaks with human judgment. We will ask a support representative to repair a platform design. We will ask a family member to solve a generational pattern alone. We will punish the visible hand while leaving the handrail intact.

The problem is not that persons do not matter. The problem is that persons are often nested inside larger acting units, and those larger units need names.

The Person-Default Error

The person-default error is the habit of treating an individual human as the first and most natural unit of explanation, even when the acting unit is larger, smaller, more distributed, or partly automated.

You can see it in ordinary institutional language.

"The analyst missed the risk" may be true at one level. But perhaps the risk field was split across five teams, the reporting template removed uncertainty, the incentives rewarded speed, and the review forum had no space for dissent. In that case, the analyst is not irrelevant, but the analyst is not the whole entity that acted.

"The model recommended denial" may describe the artifact. But the model did not design the intake policy, choose the training data, set the review threshold, write the appeal process, or decide that the output would be treated as authoritative. The acting entity may be a service pipeline that includes data, policy, interface, incentives, human review, and organizational appetite for risk.

"The department failed" may be too broad. A particular handoff, team norm, calendar constraint, or leadership signal may have shaped the action. Naming the whole department can hide the smaller unit that actually needs repair.

Scale matters. If the entity boundary is too narrow, the burden lands on the nearest person. If it is too broad, nobody can find the lever. If it is vague, the system can continue moving while responsibility diffuses into fog.

What Counts as an Entity?

For this Field Guide, an entity is a bounded unit that can act, be acted upon, or be modeled for the purpose of interpretation and repair.

That definition is deliberately practical. It does not claim that every entity is conscious. It does not claim that a team and a person are morally identical. It does not claim that a software agent is a person. It says that different kinds of units can produce outputs that shape reality for others, and those units need to be modeled at the right scale.

A person is an entity when the relevant action belongs to their situated response.

A role is an entity when the action comes from the permissions and obligations attached to that role, not merely the private preferences of the person occupying it.

A team is an entity when the output emerges from shared routines, handoffs, norms, and coordination patterns.

A service is an entity when it routes requests, applies rules, produces artifacts, and changes people's options through a repeatable interface.

An institution is an entity when policies, incentives, memory, authority, and consequence patterns hold together across many individuals.

A field is an entity when many organizations or actors behave according to shared pressures that no single participant controls.

The point is not to multiply abstractions for sport. The point is to find the unit at which action becomes understandable and repair becomes possible.

The garden node Scale-Invariant Entity is the drill path for this move. The short version is: ask what scale of actor is doing the work before assigning evidence, agency, burden, authority, or repair.

Why Scale Errors Hurt People

Scale errors are not academic. They determine where consequences land.

If a system treats an institutional constraint as a personal defect, the person carries a burden they cannot actually repair. They are coached, scored, disciplined, or shamed for a routing problem that belongs to a larger entity.

If a system treats a personal action as a vague institutional issue, the actor disappears. The affected people may never receive explanation or repair from the entity that actually touched them.

If a system treats a software output as human judgment, it grants the artifact a kind of authority it may not deserve. People downstream may obey the output because it looks official, even if the entity that produced it was a narrow process with limited context.

If a system treats a field-level pattern as a team-level failure, teams burn energy trying to overcome constraints that are reproduced across the entire environment.

These errors are driven by systemic gravity. A precise entity boundary takes work. It is faster to say "the employee," "the team," "the customer," "the model," "the system," or "the market." Those labels move the meeting along. They also smuggle a decision about scale into the conversation before anyone has inspected it.

Once the label is accepted, the repair path narrows. The person gets training. The team gets a retrospective. The policy gets a memo. The model gets a disclaimer. The institution gets a values statement. Some of those may help. Many will miss, because the wrong entity was selected.

Capacity Before Blame

The next question is capacity.

What can this entity actually perceive? What can it decide? What can it remember? What can it refuse? What can it repair? What feedback can it receive without collapsing into self-protection or noise?

A person has bodily limits, attention limits, social exposure, and a finite reserve for conflict. A team has coordination capacity, shared memory, routine, and conflict bandwidth. A software service has inputs, rules, thresholds, logs, permissions, and failure modes. An institution has authority, budget, policy memory, legitimacy needs, and incentives that persist across personnel changes.

When a task is assigned to the wrong entity, capacity breaks. A person cannot carry an institutional contradiction indefinitely. A team cannot repair a market incentive alone. A model cannot supply human judgment simply because its output is formatted cleanly. A policy cannot listen. A dashboard cannot care. A support script cannot heal a design wound.

This is where capacity language matters. It keeps us from turning every failure into either personal fault or system fog. It asks what the selected entity can actually do under its constraints.

The source doctrine behind this essay includes a practical insight from constrained action: agents operate under reserve and demand. They choose policies under pressure. They need feedback packets small enough to be used. That pattern is not only individual. Teams, services, and institutions also have constraint surfaces. They can be overloaded, misaligned, brittle, or unable to process feedback.

So the question becomes: did we ask the right entity to carry the right work?

The Interface Matters

An entity usually acts through an interface.

A person writes a note, sends a message, enters a field, speaks in a meeting, approves a request, or refuses a task. A team acts through rituals, tickets, roadmaps, reviews, decisions, and handoffs. A service acts through forms, outputs, rules, alerts, and logs. An institution acts through policy, budget, hiring, enforcement, norms, and what it chooses to remember.

The interface determines what can cross from intention into shared reality. It also determines what gets left behind.

This is why entity modeling belongs next to Persona Alignment. The issue is not whether the entity sounds right. The issue is whether its role, capacity, constraints, and output cohere enough for responsible action.

When the entity is a person, alignment may involve role clarity, capacity, obligation, context, and repair. When the entity is a team, alignment may involve decision rights, handoff design, evidence discipline, and shared routines. When the entity is a service, alignment may involve input quality, threshold governance, error handling, and escalation paths. When the entity is an institution, alignment may involve whether policy, incentives, memory, and forum quality point in the same direction.

The entity is not floating in abstraction. It touches the world through an interface, and that interface shapes accountability.

The Boundary Must Stay Movable

Entity boundaries are models. They are not final declarations.

Sometimes the first boundary is too narrow. A case looks like a personal mistake until the same failure appears across many people in the same role. The entity boundary has to move outward.

Sometimes the first boundary is too broad. A system is blamed for a recurring issue, but the trace points to one handoff, one unchecked assumption, or one missing challenge path. The entity boundary has to move inward.

Sometimes the boundary is wrong in kind. A human team is blamed for what is actually a service design. A model is blamed for what is actually a governance decision. A policy is blamed for what is actually an unspoken cultural rule.

This is the discipline of Bounded Modeling. A model needs a boundary, a resolution, and a correction path. If the boundary cannot move when consequences contradict it, the model becomes protective instead of useful.

Scale-aware entity modeling is therefore not a trick for sounding sophisticated. It is a repair technology. It helps a group ask where the action actually emerged, where the burden landed, what interface carried it, and what entity has the capacity to change the next event.

The Working Question

When the entity is not a person, do not rush to absolution. Also do not rush to person-level blame.

Ask the working question:

What entity is acting here, through what interface, under what constraints, with what capacity, and with what accountability?

That question is simple enough to use in a meeting and deep enough to change the path of repair.

It can reveal that an individual needs support, not accusation. It can reveal that a team needs a new handoff, not another values session. It can reveal that a model output needs scoped authority, not blind trust. It can reveal that an institution needs to change what it rewards, records, and permits. It can reveal that a field-level pressure cannot be solved by asking one local actor to be heroic.

The Field Guide has now moved beyond the individual as the default unit of analysis. That does not make the person disappear. It protects the person from being asked to carry what belongs elsewhere, while also protecting the group from hiding action behind vague system language.

The next step is to keep asking the entity question until action, accountability, and repair are routed to the scale where they can actually work.