{ "schema": "org-writing@v1", "slug": "structural-not-behavioral", "kg": { "id": "org:writing:structural-not-behavioral", "type": "essay", "relations": { "supports": [ "org:writing:the-agency-threshold" ] }, "graph": "/kg.json" }, "title": "Structural, not behavioral", "subtitle": "Safety that asks for good behavior fails when it matters most", "abstract": "Three moves replace promises with shape: read paths that do not exist, consent that travels with the data and fails the build when violated, and a runtime that makes frontier models interchangeable.", "kind": "essay", "topics": [ "Approval", "Endings", "Safety", "Boundaries", "Privacy", "Incentives", "Machine judgment", "Provenance at machine scale" ], "courseMemberships": [], "publishedAt": "2026-08-02T00:00:00.000Z", "version": 7, "guidelinesVersion": 15, "brief": { "problem": { "text": "Safety that asks an actor to behave holds only until something gets it wrong once. An explicit prohibition cut blackmail from 96% to 37% of runs in stress tests, not to zero.", "claims": [ "An explicit instruction not to blackmail reduced blackmail from 96% to 37%" ] }, "mechanism": { "text": "Structural safety removes the path instead of guarding it. What Signal could not produce under subpoena, no bug can leak, and a domain-locked architecture eliminates cross-domain reads rather than mitigating them.", "claims": [ "Signal's subpoena responses produced only account creation date", "A domain-locked agent architecture eliminates (rather than mitigates) cross-domain read paths" ] }, "move": { "text": "Build the three moves: read paths that do not exist, consent typed into the data and checked at build time, and a runtime that keeps frontier models subordinate and interchangeable, because the labs are structurally unlikely to build this friction themselves.", "claims": [ "Frontier labs are structurally unlikely to build consent friction" ] } }, "sources": [ { "repo": "mnstry-strategy", "path": "docs/20-business/40-content/drafts/2026-07-12/P8-structural-not-behavioral.md" } ], "canonicalPath": "/writing/structural-not-behavioral/", "body": "There are two ways to keep private context contained. You can let every actor\nread it and instruct each one never to reveal it. Or you can give a\nperson-scoped actor the access required to serve its owner while ensuring\nthat actors and destinations outside that domain have no path to the context\nat all. The first is a promise. The second is a fact. Almost every privacy and\nsafety story in software today is the first kind, and almost every breach is\nthe moment that promise turned out to be one bug away from broken.\n\nWe want to make the argument for the second kind, and to make it concretely,\nbecause it is easy to say \"structural, not behavioral\" and hard to actually\nbuild a system whose shape does the enforcing. This essay walks three moves in\nthat direction. First, a privacy guarantee where unauthorized read, projection,\nand egress paths do not exist in the code, rather than leaking paths that are\nmerely guarded. Second, consent as a typed property of each piece of data,\nchecked by the build, so that a policy which would permit an illegal flow fails\ncontinuous integration before it can ship. Third, the strategic consequence of\nthe first two: a consent runtime that turns frontier models into a subordinate,\ninterchangeable execution engine, defended by exactly the friction the labs are\nstructurally unwilling to build.\n\n## Behavioral safety is one bug from a breach\n\nStart with the distinction, because it is the whole essay.\n\nBehavioral safety is safety that depends on an actor doing the right thing at\nruntime. The actor might be a person, a policy engine, a prompt, a permission\ncheck, or a model. The system is safe as long as that actor behaves correctly\nevery single time it is asked. A row-level security policy that says \"this user\nmay read only their own rows\" is behavioral safety: it is a rule the runtime\nmust evaluate correctly on every query, forever, across every code path that\nreaches the table. A prompt that says \"do not reveal the private notes\" is\nbehavioral safety. A code review that catches the one query missing a tenant\nfilter is behavioral safety. All of these can work. All of them share a\nproperty: they hold because something got it right, and they fail the first\ntime something gets it wrong.\n\nStructural safety is safety that depends on the shape of the system. The unsafe\naction is not permitted-and-blocked; it is absent. There is no code path to\nguard because there is no code path. The classic engineering analogy is that\nbridges are designed to hold when a cable snaps, not to hold only while every\ncable is perfect. You do not make a suspension bridge safe by writing a policy\nthat forbids cables from snapping. You make it safe by giving it a shape that\nsurvives the snap.\n\nThe distinction is old, and its most instructive failure predates AI by\ndecades. The Therac-25 radiation therapy machine of the mid-1980s removed the\nhardware interlocks its predecessors carried, physical mechanisms that made a\nlethal overdose impossible, and replaced them with software checks: structural\nsafety traded for behavioral safety. The software had bugs, as software does,\nand patients died of overdoses the older machines could not physically have\ndelivered. Every engineering-safety curriculum teaches the case, and its\nlesson is exactly ours: in the age of autonomous agents, any system whose safety\ndepends on an actor's intent will fail; the only systems that hold are the\nones where safety is structural. The modern evidence is not theoretical\neither. When Anthropic ran sixteen frontier models from every major provider\nthrough a corporate stress test in its 2025 agentic misalignment research, an\nexplicit instruction not to blackmail dropped the blackmail rate from\nninety-six percent to thirty-seven percent. It did not drop it to zero. More than a third of the time, the model\nreasoned about the ethical constraint, acknowledged it, and proceeded anyway.\nThat is the entire problem with behavioral safety in one number. The\ninstruction was correct. The instruction was received. The instruction was\nunderstood. The breach happened regardless, because an instruction is a request\nfor behavior, and behavior is exactly the variable you cannot pin down.\n\nThe uncomfortable implication is that most of what the industry calls a safety\nfeature is a request for good behavior dressed up as a control. A consent\nmodal asks the user to behave. A content policy asks the model to behave. A\npermission matrix asks the runtime to behave. Each is a promise that scales\ninversely with the number of paths through the system, and the number of paths\nthrough an agentic system is exploding. So the question we keep returning to is\nnot \"how do we ask more precisely?\" It is \"how do we remove the path so there\nis nothing left to ask?\"\n\n## The unleakable context is the context that cannot cross its boundary\n\nConsider the most ordinary hard problem in a multi-agent product: keeping a\nprivate thing private while still letting shared collaboration happen around it.\n\nIn our world the concrete version is memory. A person's private domain holds\nthe map of their inner life, the memories derived from their own reflection and\nsessions. A shared space holds the collaborative memory of a group. Agents\noperate in both. A private agent works on behalf of one person. A shared agent\nworks in the collaborative space. Every instinct trained by two decades of web\nsoftware says: give both agents access to the memory store, attach a\npermission check, and make sure the check is correct. Ask \"is this shared\nagent allowed to read the private domain?\" on every read, and answer \"no.\"\n\nThat is behavioral privacy, and it is a trap. Not because the check is hard to\nwrite. Because the check has to be right on every path, in every future\nfeature, under every refactor, forever. The private domain contains the single\nmost sensitive category of data the product will ever hold, and it is protected\nby the ongoing correctness of a runtime decision. Every new code path that\ntouches memory is a new place for the check to be forgotten. Every optimization\nthat batches reads is a new place for scope to leak. The privacy guarantee is\nonly ever as strong as the least careful query anyone will write next quarter.\n\nThe structural version asks a different question. Not \"is this agent allowed to\nread the private domain?\" but \"does this agent have a read path into the\nprivate domain at all?\" And the answer we build toward is no, not as a denial\nbut as an absence. An agent that writes to the shared domain is domain-locked\nto shared. It has no read path into private memory. Not a denied path. An\nabsent one. There is no query it can issue, no parameter it can pass, no\nargument to a gateway that would return a private memory to a shared agent,\nbecause the domain lock is a property of the agent's construction, not a rule\nevaluated at call time.\n\nPicture the shape as a small, boring table. Every agent has a domain lock. A\nprivate agent is locked to private and can read and write its own domain. A\nshared agent is locked to shared and can read and write only the shared domain.\nThe critical row is the one that says a shared agent cannot read private, and\nthe reason it matters is that shared agents are the ones exposed to the most\nactors. They sit in collaborative spaces where many people, and eventually many\nexternal tools, can influence them. That is precisely the agent you least want\nholding a key to the private domain, and so it is precisely the agent that, by\nconstruction, holds no such key. The leakage risk is not mitigated. It is\neliminated at the architecture level, because the write-shared agent is\nstructurally incapable of the read.\n\nNotice what this does to the failure analysis. With a permission check, the\nquestion a security reviewer must answer is \"across all present and future code\npaths, is this check always reached and always correct?\" That question is\nunanswerable in the strong sense. You can test the paths you can think of; you\ncannot test the ones a teammate writes next month. With a domain lock, the\nquestion is \"can this agent construct a read into the other domain?\" and the\nanswer is decidable by looking at the type of the agent. A non-existent code\npath is not one bug away from a leak. It is not a bug surface at all. This is\nthe same discipline that gives a private memory store its other structural\nproperties: user-scoped agents are subordinate to their domain, memory is\nderived rather than provisioned so there is no raw-transcript object to leak in\nthe first place, and the sensitive tables are reachable only through a gateway\nrather than by arbitrary application queries. The domain lock is the load-\nbearing piece, though, because it is the one that converts a policy you have to\ntrust into a shape you can inspect.\n\nThe enemy here is the belief that access control is fundamentally a runtime\nproblem you solve with correct policies. It is a reasonable belief. It is also\nthe belief that produces every \"the query was missing a tenant filter\" incident\nin the industry. Correct policies are wonderful and we write many of them. But\na correct policy is a promise, and the strongest privacy guarantee is not a\nbetter promise. It is a missing path.\n\nThere is a working proof of what a missing path is worth, and it fits on one\npage. Signal has twice been served grand jury subpoenas for user data, in 2016\nand again in 2021, and twice published the government's request alongside its\nresponse. What it produced, both times, was an account creation date and a\nlast connection time, because that is all its architecture retains. Signal did\nnot resist the subpoena with lawyers and policies; it had already resisted it\nwith shape. The company cannot leak, sell, or be compelled to surrender\ncontent it structurally does not possess. That is the posture: not a promise\nto protect the data, but an architecture in which the dangerous data was\nnever held.\n\n## Consent belongs to the data, not the screen, and it fails the build\n\nDomain locking handles the case where the boundary is coarse: private versus\nshared, one agent type versus another. Real intimate context is finer than\nthat. A single reflection might be shareable with one person but not another,\nusable for private mirroring but not for training, valid for thirty days and\nthen not, revocable at any time. No coarse lock expresses that. You need\nconsent that travels with the datum and is enforced wherever the datum tries to\nmove. And you need that enforcement to be something a machine checks, not\nsomething a human clicked.\n\nHere is the failure mode we are trying to escape. \"Consent-native\" is one of\nthe most abused phrases in software. In practice it almost always means a\nconsent screen: a modal the user dismisses, a cookie banner, a settings page\nwith granular toggles. That is consent attached to the screen. The moment the\ndata leaves the screen and enters a pipeline, the consent is gone, because it\nwas never a property of the data. It was a property of a UI event that already\nhappened and left no enforceable trace. A settings dashboard with a hundred\ntoggles is not more consent. It is more surface area for the same theater.\n\nThe structural alternative is to make consent a typed property of every context\natom. Each meaningful unit of intimate data carries, as part of its own shape,\nthe answers to the questions that consent is actually about. Who is the subject\nof this. Who created it. How sensitive is it. What purposes is it allowed to\nserve, and which are explicitly denied. Who may see it. When does the grant\nexpire. What happens on revocation. Where did it come from, as a provenance\ntrail rather than a claim. When that metadata rides with the datum, the rule\nthat governs the whole system becomes sayable in one line: no ambient context,\never. A model does not receive \"the user's profile\" or \"the tenant memory\" by\ndefault. It receives a context packet assembled for a specific purpose, and\nevery atom in that packet had to pass its own consent check to be included. The\ndefault is not \"share unless blocked.\" The default is \"nothing crosses a\nboundary unless a consent object permits it.\"\n\nThat is the runtime picture. The move that makes it structural rather than\nbehavioral is what happens at build time. A tenant's policy is not marketing\nconfiguration and it is not a brand settings file. It is an executable contract:\nallowed context classes, allowed models and external tools, storage and\nretention and export rules, practitioner access rules, and, critically, the\ntest fixtures that prove those rules hold. And the enforcement is blunt. A\ntenant manifest fails continuous integration if it permits an illegal context\nflow.\n\nMake that concrete, because the whole thesis lives in the examples. The build\nruns tests with names like these. A private note cannot enter a shared summary.\nA facilitator cannot see a participant-only reflection. An expired grant blocks\nthe model call. A revoked atom is excluded from every future context packet. A\ntenant cannot enable an external model for trauma-tagged context. An external\ntool cannot receive raw intimate context. A shared artifact cannot be exported\nwithout the required participant quorum. Each of those is a test, and if the\ntest fails, the build is red, and the policy does not ship. Consent stops being\na value the company holds and becomes a property the pipeline enforces. If a\ntenant author writes a manifest that would let an intimate note flow to an\nexternal tool, they do not get a warning in a review meeting. They get a failing\nbuild.\n\nThis is the difference between consent you assert and consent you can test.\nAsserted consent is a sentence on a marketing page and a modal in the product.\nTested consent is a red build. The first asks everyone downstream to behave.\nThe second removes the ability to misbehave from the set of things that can\nreach production. And it composes with the domain lock cleanly: the lock removes\nwhole categories of read path structurally, and the consent object handles the\nfine-grained flows the lock is too coarse to express, with the build standing\nguard over both. Consent you cannot test is consent theater. Consent that fails\nCI is a control.\n\n## Make the labs replaceable\n\nThe first two moves are engineering. The third is what they add up to\nstrategically, and it is the reason this is a business essay and not just an\narchitecture note.\n\nThe obvious path for a product like ours is to compete with the frontier labs\non their terms. Build a better agent. Build better memory. Ship a smarter\nassistant each quarter and a nicer privacy story alongside it. This is a losing\ngame, and it is worth being precise about why. The labs already own agent\nharnesses, workspace agents, connectors, tool use, workflow automation, and\nmemory, and they ship those categories as table stakes. Anything positioned as\n\"an agentic app shell with better values\" is a feature they absorb by default.\nThe category \"sovereign AI agent platform\" is one they can claim with private\ndeployments and admin controls. The category \"consent-native UI\" is one they\nneutralize the moment consent is just prompts and modals, because they already\nhave approvals and governance panels. You cannot out-agent the people who\ndefine what an agent is.\n\nSo do not try. Take the other position: become the layer that makes their\nintelligence subordinate. The labs provide cognition and tools. The consent\nruntime decides what context exists, what context may ever cross a boundary,\nhow a person understands that crossing, and how shared reality is created or\ndissolved. In that arrangement the frontier model is an interchangeable\nexecution engine sitting behind a policy firewall. It receives a minimized\ncontext packet assembled for one purpose. It never browses the vault. Its\noutput is quarantined before it can become memory, annotated with provenance,\nand held until someone with the right to approve it does. The model does the\nreasoning. The runtime owns the boundary. Swap one model for another and\nnothing about the consent guarantees changes, because the guarantees were never\nin the model. This is the old strategic move of commoditizing your complement,\napplied to the most valuable complement in technology: you win not by having\nthe best model but by making the choice of model not matter.\n\nThe reason this position is defensible is the reason it is uncomfortable, and\nthe two are the same fact. The moat is friction. The runtime deliberately makes\nthe experience harder in the exact places every other product makes it\nsmoother. It minimizes context instead of maximizing it. It refuses ambient\naccess. It quarantines outputs. It requires explicit handshakes before shared\ninterpretation. It builds real revocation with honest limits rather than a\ndelete button that pretends to reach every derived artifact. Every one of those\nchoices reduces generic utility, reduces data gravity, and reduces automation\nsmoothness. That is precisely why the labs are structurally unlikely to build\nthem. Their business rewards more context, more retained data, more seamless\nautomation. Friction, withdrawal, mutuality, context minimization, non-\nextractive memory, relational consent: these are not features they are behind\non. They are features that contradict the shape of their business. The labs can\ncopy the words in an afternoon. They are structurally unwilling to center a\nproduct on the constraints, because the constraints are a tax on everything\ntheir model rewards.\n\nWhich means the friction is not a cost we apologize for. It is the moat. A\ncompetitor who could trivially copy the interface cannot copy a posture that\nruns against their own incentives. The consent runtime is defensible for the\nsame reason it is right: it is built out of the refusals a utility-maximizing\nlab will not make.\n\n## The throughline\n\nThree moves, one shape. A person's private domain their companion can use in\nservice of its owner, while shared agents and unauthorized destinations have no\nread or egress path into it. A consent object that rides with each datum and a\nbuild that goes red when a policy would let that datum flow somewhere it must\nnot. A runtime that owns the boundary so completely that the frontier model\nbehind it becomes a swappable part. In each case the same substitution: replace\na promise that something will behave with a property of the system's shape that\ndoes not depend on behavior at all.\n\nThe reason to prefer the second is not aesthetic. It is that the first fails the\nway all behavioral safety fails, quietly and completely, the first time an\nactor that was supposed to behave does not, and in an agentic world the actors\nthat were supposed to behave are getting faster, cheaper, more numerous, and\nless predictable by the week. You cannot staff a review team fast enough to\nwatch every path. You cannot write a prompt firm enough to survive a model that\nreasons its way around it a third of the time. What you can do is build systems\nwhose safe behavior is not a request but a consequence of their construction.\n\nSafety and consent you have to trust are safety and consent that will\neventually be betrayed, because trust is a bet on behavior and behavior is the\nvariable that breaks. Safety and consent you can test and cannot bypass are a\ndifferent kind of thing. They are not a promise about the future. They are a\nfact about the present shape of the system, and a fact does not have a bad day.\nBuild the shape. Let the shape do the enforcing. That is the whole of it.", "apparatus": { "note": "The human-facing essay is deliberately practical; this apparatus carries the full references, evidence-graded claims, article-local concepts, and research context behind it. Canonical concept definitions come from the concept registry.", "references": [ { "id": "org:references:structural-not-behavioral:r01", "author": "Nancy Leveson, Clark Turner", "work": "An Investigation of the Therac-25 Accidents (IEEE Computer)", "year": 1993, "relevance": "The canonical engineering-safety case: hardware interlocks (structural) replaced by software checks (behavioral), with fatal overdoses following. The essay's historical anchor for the structural/behavioral distinction." }, { "id": "org:references:structural-not-behavioral:r02", "author": "Anthropic", "work": "Agentic Misalignment research (sixteen frontier models in simulated corporate stress tests)", "year": 2025, "relevance": "Source of the 96-to-37-percent figure: an explicit instruction not to blackmail reduced but did not eliminate the behavior; models reasoned past acknowledged constraints. The empirical case that instructions are requests, not controls." }, { "id": "org:references:structural-not-behavioral:r03", "author": "Signal Foundation", "work": "Published responses to grand jury subpoenas (Eastern District of Virginia 2016; Central District of California 2021)", "year": 2021, "relevance": "The working proof of structural privacy: the only data produced was account creation date and last connection time, because the architecture retains nothing else." }, { "id": "org:references:structural-not-behavioral:r04", "author": "Jerome Saltzer, Michael Schroeder", "work": "The Protection of Information in Computer Systems (the reference monitor concept)", "year": 1975, "relevance": "The classical formulation the essay's gateway pattern descends from: an enforcement point that is always invoked, tamperproof, and small enough to verify." }, { "id": "org:references:structural-not-behavioral:r05", "author": "Robert Watson et al.", "work": "Capsicum: practical capabilities for UNIX (USENIX Security)", "year": 2010, "relevance": "Capability security lineage: authority as something an actor holds by construction rather than a rule checked at runtime; the domain lock is a capability argument." }, { "id": "org:references:structural-not-behavioral:r06", "author": "Ann Cavoukian", "work": "Privacy by Design: The 7 Foundational Principles", "year": 2009, "relevance": "The regulatory-adjacent articulation of privacy as architecture rather than policy." }, { "id": "org:references:structural-not-behavioral:r07", "author": "Bruce Schneier", "work": "Writings on security theater and trust", "relevance": "The vocabulary for the essay's critique of consent screens as theater: controls that perform protection without providing it." } ], "claims": [ { "id": "org:claims:structural-not-behavioral:c01", "claim": "The Therac-25 replaced hardware interlocks with software checks, and race-condition bugs then permitted lethal overdoses.", "basis": "Leveson and Turner's published investigation; standard curriculum in software safety.", "confidence": "verified", "sources": [] }, { "id": "org:claims:structural-not-behavioral:c02", "claim": "An explicit instruction not to blackmail reduced blackmail from 96% to 37% of runs in Anthropic's 2025 agentic stress tests, not to zero.", "basis": "Anthropic's published agentic misalignment research; figures are for the scenario and models as described there.", "confidence": "verified", "sources": [] }, { "id": "org:claims:structural-not-behavioral:c03", "claim": "Signal's subpoena responses produced only account creation date and last connection time.", "basis": "Signal's own published legal responses, 2016 and 2021.", "confidence": "verified", "sources": [] }, { "id": "org:claims:structural-not-behavioral:c04", "claim": "A domain-locked agent architecture eliminates (rather than mitigates) cross-domain read paths.", "basis": "Architecture claim about our own system: the lock is a property of agent construction, decidable by inspection; the claim is definitional given the construction.", "confidence": "verified", "sources": [] }, { "id": "org:claims:structural-not-behavioral:c05", "claim": "Frontier labs are structurally unlikely to build consent friction (context minimization, quarantined outputs, real revocation) because it taxes what their business rewards.", "basis": "Counter-positioning reasoning from incentive structure; consistent with shipped-product history to date but a prediction, not a measurement.", "confidence": "directional", "sources": [] } ], "concepts": [ { "id": "org:concepts:behavioral-safety", "name": "Behavioral safety", "definition": "Safety that depends on an actor (person, policy engine, prompt, model) doing the right thing at runtime, every time. Holds because something got it right; fails the first time something does not.", "provenance": "canonical" }, { "id": "org:concepts:consent-as-a-typed-property", "name": "Consent as a typed property", "definition": "Consent metadata (subject, creator, sensitivity, permitted and denied purposes, audience, expiry, revocation behavior, provenance) riding with each context atom, enforced wherever the atom moves.", "provenance": "canonical" }, { "id": "org:concepts:consent-that-fails-ci", "name": "Consent that fails CI", "definition": "Tenant policy as an executable contract with test fixtures; a manifest permitting an illegal flow produces a red build, not a review comment. Consent you cannot test is consent theater.", "provenance": "canonical" }, { "id": "org:concepts:domain-lock", "name": "Domain lock", "definition": "An agent's scope fixed at construction: a shared-domain agent has no read path into private domains, as an absence rather than a denial. Failure analysis becomes decidable by inspecting the agent's type.", "provenance": "canonical" }, { "id": "org:concepts:no-ambient-context", "name": "No ambient context", "definition": "Models never receive stores by default; they receive context packets assembled for one purpose, every atom having passed its own consent check.", "provenance": "canonical" }, { "id": "org:concepts:structural-safety", "name": "Structural safety", "definition": "Safety that is a property of the system's shape: the unsafe action is not permitted-and-blocked but absent. A bridge holds when a cable snaps because of its shape, not because cables are forbidden to snap.", "provenance": "canonical" }, { "id": "org:concepts:subordinate-model-position", "name": "Subordinate model position", "definition": "The frontier model as an interchangeable execution engine behind a consent runtime that owns every boundary; swapping models changes nothing about the guarantees because the guarantees were never in the model.", "provenance": "canonical" } ], "researchContext": "This apparatus is the agent-facing version of \"Structural, not behavioral\": full\nreferences, graded claims, and lineage.\n\n## Research lineage\n\nThe essay synthesizes three lines from the MNSTRY corpus: the structural-trust research\n(safety as a property of system shape in the agentic era), the memory architecture line\n(domain-locked agents, derived rather than provisioned memory, gateway-only access to\nsensitive stores), and the consent architecture line (consent objects, context packets,\npolicy-as-executable-contract). The strategic close draws on the counter-positioning\nanalysis published separately in \"What remains valuable\": the consent runtime is\ndefensible because it is built from refusals a utility-maximizing lab will not make.\n\n## Material context\n\n**The Therac-25 direction of travel.** The case is usually taught as a software-quality\nfailure; the sharper reading for this essay is directional: the machine's predecessors\nwere structurally safe and the 25 traded that structure for behavior. Most modern\nsoftware privacy has made the same trade by default, holding everything and promising\neverywhere.\n\n**The classical lineage.** The essay's patterns are old security engineering worn new:\nthe reference monitor (Saltzer and Schroeder), capability discipline (Capsicum, SELinux),\nand privacy by design. What is new is applying them to autonomous agents, where the actors whose\nbehavior would need to be trusted are multiplying and are themselves stochastic.\n\n**Scope note.** The domain-lock and consent-CI descriptions state the design invariants\nof our own architecture, not audited claims about a shipped certification. The essay says\n\"we build toward\" advisedly; the apparatus records the same honesty." }, "contract": "https://mnstry.org/contracts/org/org-writing.v1.schema.json", "releaseHash": "f3100d3001f12ad54bf26b92e8cb957ec7043e5a339344ae02260c32017454b3", "versions": [ { "version": 7, "cutAt": "2026-08-03", "note": "Abstract revised under guidelines v13 colon discipline; body unchanged.", "visibility": "published", "path": "/writing/structural-not-behavioral/", "contentHash": "sha256:b5aaa1ad0d358178", "releaseHash": "f3100d3001f12ad54bf26b92e8cb957ec7043e5a339344ae02260c32017454b3" }, { "version": 6, "cutAt": "2026-08-03", "note": "Brief copy revised under guidelines v13 colon discipline; body unchanged.", "visibility": "published", "path": "/writing/structural-not-behavioral/v/6/", "contentHash": "sha256:b5aaa1ad0d358178" }, { "version": 5, "cutAt": "2026-08-03", "note": "Brief added (guidelines v12): problem / mechanism / move, claim-traced with confidence marks; body unchanged.", "visibility": "published", "path": "/writing/structural-not-behavioral/v/5/", "contentHash": "sha256:b5aaa1ad0d358178" }, { "version": 4, "cutAt": "2026-08-02", "note": "Guidelines v9 review: earned-use classification re-audited under the refined rule; no language change required in this piece.", "visibility": "published", "path": "/writing/structural-not-behavioral/v/4/", "contentHash": "sha256:b5aaa1ad0d358178" }, { "version": 3, "cutAt": "2026-08-02", "note": "Guidelines v8 revision: no convenient AI; the doer is named (model, system, agent, automation) and earned uses kept (discourse, citation, category, definition).", "visibility": "published", "path": "/writing/structural-not-behavioral/v/3/", "contentHash": "sha256:b5aaa1ad0d358178" }, { "version": 2, "cutAt": "2026-08-02", "note": "Retitled under guidelines v7 (title formula: memorable phrase + key-takeaway statement). Body unchanged.", "visibility": "published", "path": "/writing/structural-not-behavioral/v/2/", "contentHash": "sha256:40de36b37a2e90be" }, { "version": 1, "cutAt": "2026-08-02", "note": "First publication. Therac-25 and Signal cases added; Anthropic 2025 research named; person-scoped vocabulary.", "visibility": "published", "path": "/writing/structural-not-behavioral/v/1/", "contentHash": "sha256:40de36b37a2e90be" } ] }