InquirySpec - Ontological Boundary: A Scale-Invariant Entity is any unit that can act or be modeled across person, role, group, service, or institution scale. - Not This: Not a claim that all entities are morally equivalent. - Doctrine Dependencies: Persona Alignment, CE+HR.
Working Definition
A Scale-Invariant Entity is a bounded unit that can act, be acted upon, or be modeled across multiple scales. The unit might be a person, role, relationship, team, service, institution, field, software agent, cohort, or larger system.
The concept is scale-invariant because the same first question applies at every level: what is the acting unit in view? Before interpreting an artifact, assigning responsibility, routing evidence, or designing repair, the system must know whether the relevant actor is one person, a small group, an organization, a service pipeline, a public institution, or a broader field.
Scale-invariant does not mean identical. A person and an institution are not morally, legally, biologically, or operationally equivalent. They do not have the same memory, authority, vulnerability, repair path, or consequence surface. The invariant is the modeling discipline, not the substance of the entity.
The Phenomenological Problem
Many coordination failures begin as scale errors. A team misses a deadline, and the explanation is assigned to one person's motivation. A single employee makes a visible mistake, and the remedy becomes an organization-wide policy that burdens everyone. A generated report speaks with the confidence of an institution, even though it is only summarizing a narrow source. A platform rule affects thousands of people, but the support script treats each case as an isolated user problem.
These errors are not usually produced by careful analysis. They are produced by systemic gravity. Under pressure, institutions choose the easiest actor label available: "the user," "the team," "management," "the model," "the system," "the market." The label keeps the workflow moving, but it may point attention at the wrong scale.
When the acting unit is wrong, repair misses. Coaching does not fix a policy maze. A policy update does not repair a broken relationship. A dashboard does not explain a field-level incentive pattern. A team retrospective cannot solve a vendor ecosystem constraint by itself.
Scale-Invariant Entity exists to stop that drift before it hardens into action.
The Engineering Anchor
The internal persona doctrine redefines identity as a scale-aware acting unit. The public version is simpler: do not assume that "actor" means individual human. Actors can be nested, composite, distributed, automated, historical, or institutional. Each one needs a boundary before its output can be interpreted.
That boundary has three practical coordinates.
First, scale. Is the entity a person, dyad, team, organization, field, or system? The answer changes what evidence counts, what authority is available, and what repair is possible.
Second, temporal position. The entity is not only its present output. It carries history, inherited constraints, open commitments, and possible futures. A current action may be the visible tip of a longer lineage.
Third, action capacity. The entity must be modeled by what it can perceive, decide, authorize, refuse, record, and repair. A person can apologize. A policy can be amended. A service can be reconfigured. A field can change only through wider coordination across many entities.
This is where scale-invariance depends on Bounded Modeling. The model needs enough boundary and resolution to support action, but it must remain open to correction when reality shows that the wrong scale was selected.
It also depends on Persona Alignment. Once the acting unit is identified, its role, capacity, context, and output have to cohere. A title, label, or interface name is not enough.
Boundary Conditions
Scale-Invariant Entity is not moral equivalence. A corporation, a classroom, an AI agent, and a child can all be modeled as entities for a specific purpose, but their agency and accountability conditions are radically different.
It is not category flattening. The concept does not erase legal status, embodiment, consciousness, social power, dependency, or harm exposure. Those differences are precisely why the boundary must be explicit.
It is not a license to anthropomorphize software or depersonalize humans. A software agent can be an acting unit in a workflow without being treated as a person. A person can be part of an institutional entity without being reduced to an interchangeable component.
It is not final certainty about where the actor boundary belongs. Sometimes the first model is wrong. A problem that looks personal may be organizational. A problem that looks institutional may depend on one broken handoff. A mature system must allow the entity boundary to change when evidence and consequence show the first boundary was too narrow, too broad, or aimed at the wrong layer.
Drill Path
Use this node whenever a public essay or garden node is about to say "the actor," "the system," "the institution," "the team," "the model," or "the user." Pause and ask what scale is actually doing the work.
Ask five routing questions.
What entity is acting or being modeled?
At what scale is that entity bounded?
What authority, capacity, memory, and constraint does it have?
What consequence surface belongs to that entity?
What repair path is available at that scale?
Move next to Persona Alignment when the entity's role, capacity, context, and output need to be situated. Move to Bounded Modeling when the model boundary itself needs to be tested for scope, resolution, and correction.