[0] The .human Standard: A Proposal for Human-Sovereign Spaces in an Agentic World

We are moving fast. Faster than our file systems, our naming conventions, and our governance frameworks were ever designed to handle. AI agents today can read your spreadsheets, modify your Python scripts, browse your project folders, update your building models, and send emails on your behalf — often without you explicitly asking them to. In most workflows, that is exactly the point. But in some spaces, it should be completely off-limits. And right now, we have no agreed way to say so. This paper proposes a simple, open convention: the **`.human`** standard. A way for people to mark files, folders, and workspaces as belonging to the human layer of any collaborative system — protected from autonomous AI reading, modification, or inference, by design.

The analogy most people reach for is `.gitignore`. You create a file, you list what should be excluded from version control, and the toolchain respects it. Nobody debates whether Git *could* read those files. The point is that it *should not*, and the convention makes that boundary explicit. We need the same thing for agents. The difference is that `.gitignore` is about scope — what gets tracked — while `.human` is about *sovereignty*. It is not just saying "skip this." It is saying "this space belongs to a person, and no automated process has standing here." That distinction matters enormously as agents become more capable and more embedded in professional workflows.

The `.human` standard is not an abstract idea. It addresses real tensions that are already emerging in everyday professional workflows — from shared spreadsheets to codebases to building systems. Here are three scenarios that illustrate why the boundary matters. ### Working Together in Excel Consider a large Excel workbook used to track a construction project — costs, schedules, scope changes, supplier contacts. An AI co-pilot has been given access to assist with analysis, fill in projected values, and flag anomalies. Now imagine one sheet in that workbook is a personal risk register — informal notes made by the project manager about political dynamics, concerns about a contractor's reliability, or unresolved disagreements with the client. These notes are not wrong, they are not sensitive in a legal sense, but they are deeply human: judgment calls, half-formed thoughts, professional intuition. An agent that reads this sheet and incorporates it into a summary report, or worse, uses it to make a recommendation, has crossed a line. The human did not consent to this. The notes were not addressed to the agent. They are mental workspace, not data input. A `.human` flag on that sheet — or on a folder containing personal working documents — would make the boundary unambiguous, both to the agent and to any audit trail reviewing what the agent had access to. ### Programming in Python Software teams are already working alongside AI coding assistants that can propose changes, refactor modules, run tests, and commit code. The productivity gains are real. But consider what else lives in a typical project directory. There are personal scratch files where a developer thinks on paper — half-baked ideas, abandoned experiments, notes to self about why a particular approach was rejected. There are local configuration overrides that only make sense on one person's machine. There are files containing philosophical decisions — architecture records, decision logs — where the reasoning matters as much as the conclusion, and where an agent summarising or modifying the content would erase exactly the nuance that made it valuable. More concretely: if a developer marks a folder `decisions/.human/`, it communicates to every agent in the pipeline that this directory contains human reasoning, not machine-readable instructions. Read access might still be granted selectively, but write access is off by default. The boundary is declared, not assumed. ### Agents in an Operational Digital Twin This is where the stakes become existential rather than merely professional. Imagine a large mixed-use building — offices, apartments, shared amenities — managed through a live Digital Twin. Sensors feed data about occupancy, energy, air quality, and maintenance status into the model in real time. Agents handle routine operations: adjusting HVAC schedules, dispatching maintenance crews, optimising energy loads, flagging anomalies. The humans living and working in that building are not just users of the system. They are stakeholders with rights, preferences, and a reasonable expectation that their lives are not being optimised without their knowledge or consent. Consider a family in an apartment who have registered certain preferences with the building management system — perhaps they have a child with a medical condition that makes temperature stability important, or they have requested that their unit not be included in demand-response energy programmes. These preferences represent human decisions that should be immutable to the operational agents managing the building. Now consider a building manager who has manually overridden an automated recommendation because they know something the system does not — that a tenant is going through a difficult period, that a community event is happening next weekend, that a maintenance decision involves a contractor relationship that predates the digital system. These overrides are human judgments. An agent that re-optimises over them, even with the best intentions, has undermined the human layer of governance. A `.human` standard in this context means that certain records, overrides, and preference files carry a marker that the operational layer is structurally incapable of modifying. Not because the agent lacks capability, but because the system was designed to respect the boundary.

The scenarios above describe the *why*. The diagrams below show the *how* — two process maps that trace the decision path when an agent encounters a `.human` boundary in practice. ### Developer Workflow When an AI coding agent operates on a project, it traverses the directory tree — reading files, proposing changes, running tests. The `.human` convention introduces a clear decision point: when the agent encounters a `.human` path, it halts. No reading, no modification, no inference. The boundary is structural, not discretionary.

### Agentic Digital Twin In a building managed through a Digital Twin, agents continuously process sensor data and optimise operations. But certain records — tenant preferences, manual overrides by the facilities manager — carry a `.human` marker. The agent reads these for context but is structurally prevented from modifying them. The human layer of governance stays intact.

The beauty of a good convention is its simplicity. It does not need to solve every edge case in version one. It needs to be clear enough to be adopted, and principled enough to be extended. **At the file level**, a `.human` extension or a `_human` suffix signals that a file is sovereign. `risk-register.human.xlsx`, `architecture-decisions.human.md`, `tenant-preferences.human.json`. The agent toolchain — whether that is an MCP server, a CI/CD pipeline, a BIM authoring tool, or a building management system — checks for this marker before any read or write operation and halts if it is present. **At the folder level**, a `.human` directory signals that everything inside it is sovereign. Any agent encountering a `.human` path — whether scanning a project tree or traversing a file system — halts before entering. The convention is immediately legible to any developer. **At the workspace level**, for Digital Twin environments, the standard extends into the information model itself. An IFC property set, a COBie field, a database flag — `Human_Sovereign: true` — attached to any record that was set by a person and must not be overwritten by an automated process. The agent can read it to understand context, but the write path is blocked by policy enforced at the platform level. **Critically**, the standard should distinguish between *read protection* and *write protection*. In many cases, an agent reading a human file is acceptable — it provides context. But modifying it, deleting it, summarising it into a report it was never intended for, or using it as training signal are all different categories of access that the standard should be able to express. In practice, this looks like a `.human` prefix or suffix applied consistently across a project — simple enough to adopt immediately, principled enough to extend as tooling matures.

### .human as a Lock File There is a useful analogy hiding in plain sight. Developers already understand lock files — `package-lock.json`, `poetry.lock`, `Cargo.lock` — files that freeze the state of a system at a known-good point and prevent automated processes from silently changing it. The `.human` convention works the same way, but for *governance* rather than *dependencies*. A `.human` marker does two things simultaneously. First, it **preserves state**: the content inside a `.human` file or folder is frozen from the agent's perspective. An agent cannot update it, merge into it, or rewrite it as part of an automated workflow. The state is what the human set it to, and it remains that way until a human changes it again. Second, it **locks access**: the path is structurally excluded from the agent's write scope, exactly as a `.lock` file prevents a package manager from resolving new versions until the lock is explicitly regenerated. This dual property — state preservation plus access restriction — makes `.human` more than a permission flag. It is a *checkpoint*. In a CI/CD pipeline, the `.human` folder is the place where decisions live that the pipeline must respect but cannot alter. In a Digital Twin, the `.human` records are the baseline that operational agents optimise *around*, never *through*. In a spreadsheet, the `.human` sheet is the page that holds the thinking the model is not allowed to flatten into a summary. The parallel is instructive: just as a lock file gives a team confidence that the dependency tree will not shift under their feet, a `.human` marker gives professionals confidence that their sovereign decisions will not be rewritten by the next agent to scan the workspace.

Some will argue that permissions systems already handle this — that RBAC, ACLs, and vault policies are the right place to enforce these boundaries. They are not wrong that those tools can achieve the technical outcome. But they are solving a different problem. Permissions systems are designed around *roles* and *identities*. The `.human` standard is designed around *intent and meaning*. The question it answers is not "does this agent have permission?" but "does this content belong to the human layer of this system?" That is a richer and more honest framing. A well-configured permissions system could accidentally give an agent read access to a personal file and the system would have no way of knowing that was a mistake. A `.human` marker makes the intent explicit in the content itself — it travels with the file, it survives migration, and it is legible to anyone reviewing the system, not just to security engineers who understand the ACL configuration. In regulated industries — construction, facilities management, healthcare, critical infrastructure — this kind of explicit, auditable intent marker has real legal and compliance value. When a regulator asks "how do you ensure automated systems do not override human decisions?", pointing to a governance framework built on `.human` markers is a much cleaner answer than "we configured our permissions correctly."

### Human-in-the-Loop: The Fire Alarm Override Consider a fire alarm system in a large commercial building, managed through an agentic Digital Twin. Smoke sensors trigger, and an operational agent begins executing its emergency protocol — activating sprinklers, unlocking fire exits, notifying emergency services. This is exactly what automation should do. The agent is fast, it follows its protocol, and it gets the building evacuated. Now consider what happens after. The smoke clears — or appears to. Sensor readings normalise. The agent, processing the data, determines that conditions have returned to safe thresholds. Left to its own logic, it would issue the all-clear: "fire is out, return to the building." But the agent can be wrong. A smouldering fire behind a wall produces no smoke until it reignites. A sensor malfunction can report clean air in a room still filling with carbon monoxide. A false positive from a kitchen event looks identical, in telemetry, to a false negative from a real fire that has temporarily dropped below detection threshold. The agent cannot tell the difference. It reads the numbers, and the numbers say safe. This is where the `.human` standard becomes a life-safety mechanism. The all-clear — the signal that says "the fire is out, it is safe to return" — is locked behind a `.human` protocol. No agent can issue it. No automated process can trigger it. The building stays in evacuation state until a verified human — a facilities manager, a fire warden, or a responding firefighter — physically confirms the situation and releases the `.human`-protected override. The agent cannot countermand this. It cannot escalate past it. It cannot silently re-enable normal operations because its sensors say everything is fine. The `.human` marker on the all-clear is absolute: a human took responsibility for the evacuation, and only a human can take responsibility for ending it.

### Secrets, Credentials, and the Privacy Boundary The governance case extends naturally to software development. Every project has files that should never be touched by an agent — not because they are intellectually sovereign, but because they are operationally dangerous. Environment files (`.env`), API keys, OAuth tokens, database credentials, authentication configuration — these are the attack surface of any application, and an agent that reads, logs, or transmits them creates a privacy and security liability. Today, developers rely on `.gitignore` to keep secrets out of version control and on vault services to manage credentials at runtime. But neither convention tells an AI agent to stay away. A coding assistant that reads `.env` to "understand the configuration" has already crossed a line. One that includes a credential in a generated code snippet or a debug log has created a breach. A `.human` marker on secrets and authentication files solves this cleanly. The agent sees the boundary, halts, and works with the rest of the codebase. No special vault integration required, no custom permission rules — just a convention that says "this file belongs to the human operator, not to the automation." It is the same principle as the Digital Twin override, applied to a different domain: the human controls the keys, and the agent respects the lock.

### What This Looks Like in a Codebase In practice, adopting `.human` is as simple as creating a folder. Consider a typical project: ``` my-project/ ├── src/ │ ├── app.py │ ├── routes.py │ └── models.py ├── tests/ ├── .human/ │ ├── .env │ ├── credentials.json │ ├── oauth-tokens/ │ ├── decisions/ │ │ └── why-we-chose-postgres.md │ └── scratch/ │ └── perf-notes.md ├── .gitignore └── README.md ``` Everything under `.human/` is off-limits to agents. Secrets live there. Personal notes live there. Architecture decision records live there. The agent works freely with `src/`, `tests/`, and configuration files — but the `.human` boundary is absolute. The enforcement is minimal. Any agent framework or tool can check for it in a few lines: ```python from pathlib import Path def is_human_path(path: Path) -> bool: """Check if any component of the path is .human-marked.""" return any(part == ".human" or part.startswith(".human") for part in path.parts) # Agent-side guard — run before any file operation def agent_read(path: Path) -> str: if is_human_path(path): raise PermissionError(f"HALT: {path} is .human-protected") return path.read_text() ``` That is the entire implementation. No configuration file to maintain, no server to run, no permissions matrix to audit. The convention is in the file system itself — portable, visible, and impossible to miss. For teams already using `.gitignore`, the adoption path is familiar. Add `.human/` to your project root. Move your secrets and personal files into it. Every agent that respects the convention — and every framework that builds in the check — immediately honours the boundary. The more teams that adopt it, the stronger the signal to tool authors and AI providers: this is how humans mark their space.

There is a dimension to the `.human` standard that reaches beyond individual projects and buildings: **data sovereignty**. As AI systems operate across borders — processing data in one jurisdiction, training models in another, and serving users in a third — the question of who controls what data, and under which legal framework, becomes urgent. Regulations like GDPR, the EU AI Act, and emerging data localisation laws in dozens of countries all share a common requirement: certain categories of data must remain under human oversight, and citizens must be able to audit how their data is handled by automated systems. The `.human` standard provides a structural mechanism for meeting this requirement. When a `.human` marker is applied to a data partition — say, personally identifiable information belonging to EU citizens, or consent records governed by a national privacy authority — it creates an auditable boundary in the data flow. Agents can process anonymised or aggregated data freely, but the sovereign partition is locked: only authorised human operators can access, modify, or export it. This is not access control by configuration. It is access control by convention, embedded in the data itself and visible to any auditor.

This standard should not be owned by a single vendor. It should emerge from the communities that feel the problem most acutely: BIM practitioners, digital twin operators, enterprise software teams, and the open-source tooling projects that underpin agentic workflows. The analogy is again instructive. `.gitignore` was not invented by a standards body. It was invented by the people who needed it, it was simple enough to copy, and it became universal. The MCP ecosystem, the IFC community, the emerging agent orchestration frameworks — all of them have enough overlap in this problem that a lightweight, vendor-neutral specification is achievable. What that specification needs is not a long document. It needs agreement on three things: the marker syntax, the default behaviour when a marker is encountered (halt and log), and a minimal permission grammar for expressing read/write distinctions. Everything else — tooling, integrations, enforcement mechanisms — can be built on top of that foundation by whoever needs it.

The buildings we design and the software we write are increasingly populated by agents that are genuinely useful, often impressive, and sometimes alarmingly capable. That is a good thing. The goal of this proposal is not to slow that down. The goal is to ensure that as we build systems where humans and agents work side by side — in spreadsheets, in codebases, in buildings — we do not accidentally engineer out the human layer. Not because agents are malicious, but because the absence of a clear boundary is itself a design failure. The `.human` standard is a small idea with large implications. It says: some things are ours. Not hidden, not locked away, but *marked* — with the same clarity and simplicity we use to mark everything else we care about preserving. That boundary, stated explicitly, is the foundation of trust between human professionals and the agents they work alongside. --- *This is a living proposal. Feedback, critique, and collaboration from practitioners in BIM, Digital Twins, information management, and AI engineering is welcomed.*