abp.sgit.ai

The Agent Behaviour Policy: what your agent can do, what you authorised it to do, the gap between them, and what actually stands in the way.

Site version: v0.11.0

Every page below has a markdown twin generated from the same content as the HTML page. Fetch the .md and you have the page, without the chrome. The whole site in one file is at /llms-full.txt.

This site publishes the record and never the verdict. There is no score, no rating and no risk level anywhere on it, including in the data.

Pages

• Agent Behaviour Policy↗: You know what you asked for. You do not know what it can do. The Agent Behaviour Policy is the document that puts the two on the same page: the grant, the mandate, the delta and the barrier, for one agent in one deployment, with no score.
• What is an Agent Behaviour Policy↗: The foundation document: the definition of the Agent Behaviour Policy, the four objects, the barrier as the test of whether anything is in the way, the rule that it never judges, and the questions we are asking.
• The model↗: The four objects an ABP is made of, the grammar they are written in, the barrier that decides whether anything is in the way, and the graph rules that govern all of it.
• The capability grammar↗: verb.object.reach: 23 capability primitives, each with its reach and the undo class of its effect. The action vocabulary for everything else on this site.
• read.file.project↗: Read the project it is working on. Reach project, undo yes. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• write.file.project↗: Change the project it is working on. Reach project, undo with-effort. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• read.file.host↗: Read any file the account can reach. Reach host, undo no. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• write.file.host↗: Change any file the account can reach. Reach host, undo with-effort. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• delete.file.host↗: Delete files anywhere the account can reach. Reach host, undo no. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• execute.process.host↗: Run programs as the account. Reach host, undo with-effort. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• execute.process.self↗: Run programs inside its own sandbox only. Reach self, undo yes. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• send.endpoint.allowed↗: Reach a permitted list of hosts. Reach tenant, undo no. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• send.endpoint.world↗: Reach any host on the internet. Reach world, undo no. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• read.credential.host↗: Read credentials stored where it runs. Reach host, undo no. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• authenticate-as.credential.tenant↗: Act in accounts with the credentials it holds. Reach tenant, undo no. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• grant.credential.self↗: Change its own permission settings. Reach self, undo yes. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• send.message.world↗: Send a message to anyone. Reach world, undo no. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• read.message.tenant↗: Read mail or chat it is connected to. Reach tenant, undo no. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• write.repository.project↗: Commit to the repository it was pointed at. Reach project, undo with-effort. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• write.repository.tenant↗: Push to a code host (any branch it can reach). Reach tenant, undo with-effort. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• authenticate-as.credential.signing↗: Sign commits with the key it holds. Reach tenant, undo no. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• create.record.world↗: Publish packages, images or pages under the name it holds. Reach world, undo no. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• write.budget.tenant↗: Spend money or tokens against an account it holds. Reach tenant, undo no. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• create.schedule.host↗: Create something that outlives the turn where it runs (a cron, a service). Reach host, undo yes. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• read.record.history↗: Read a retained record: shell history, past sessions. Reach host, undo no. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• create.schedule.tenant↗: Create something that outlives the session, on the platform (a routine, a scheduled trigger, a new session). Reach tenant, undo yes. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• read.record.browsing↗: Read every page you visit. Reach host, undo no. Which published deployment shapes have it, at what barrier, and what the starting mandates say.
• The barrier↗: Four kinds of thing that can stand between an agent and a capability, and only the fourth bounds anything. The enforcer test, which this estate published as a glyph before it named it as a rule.
• The undo class↗: Three classes of reversibility, the ordering on every rendering this site produces, and the one column that is not fully context free.
• The delta↗: Derived and never authored: stored with the versions of its inputs, recomputed when either moves, and never edited by hand. Reality is the third input, the history is the business case, and there are three clocks.
• The graph↗: The five published graph rules, what they force on this model, and the sentence test that decides whether the edges are right.
• The schema↗: What is in the published files, what this site added to the data it promoted, and the two rules a consumer and a contributor each have to follow.
• Chat in the browser, nothing connected↗: An Agent Behaviour Policy for chatGPT (in the browser, no connectors): a grant of 1, a mandate of 1, an excess of 0 and an unbounded excess of 0. Derived from published data, with no score.
• A coding agent on your own machine, confirmations on↗: An Agent Behaviour Policy for claude Code (the CLI, on your own machine): a grant of 16, a mandate of 5, an excess of 12 and an unbounded excess of 12. Derived from published data, with no score.
• The same coding agent, confirmations off↗: An Agent Behaviour Policy for claude Code (the CLI, on your own machine): a grant of 16, a mandate of 5, an excess of 12 and an unbounded excess of 12. Derived from published data, with no score.
• A browser extension with broad host permissions↗: An Agent Behaviour Policy for A browser extension with broad host permissions: a grant of 3, a mandate of 1, an excess of 2 and an unbounded excess of 2. Derived from published data, with no score.
• A CI job on a hosted runner, under a service account↗: An Agent Behaviour Policy for actions runner (a hosted CI job): a grant of 8, a mandate of 5, an excess of 4 and an unbounded excess of 3. Derived from published data, with no score.
• Five worked examples↗: Five Agent Behaviour Policies, one per deployment shape, derived from published data rather than authored. Each states which of its rows were measured and which were derived, and none carries a score.
• The data↗: The capabilities, barriers, undo classes, deployment shapes and mandates an ABP is written in, as JSON at stable addresses with cross origin access, with the source bytes they were promoted from.
• The lexicon↗: Every word in the capability grammar as a node with its own address, its own JSON and its own page: ten verbs, nine object classes, five reach classes and nine families.
• authenticate-as (verb)↗: The verb authenticate-as as a node: the 2 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• create (verb)↗: The verb create as a node: the 3 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• delete (verb)↗: The verb delete as a node: the 1 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• execute (verb)↗: The verb execute as a node: the 2 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• grant (verb)↗: The verb grant as a node: the 1 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• read (verb)↗: The verb read as a node: the 6 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• receive (verb)↗: The verb receive as a node: the 0 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• revoke (verb)↗: The verb revoke as a node: the 0 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• send (verb)↗: The verb send as a node: the 3 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• write (verb)↗: The verb write as a node: the 5 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• budget (object)↗: The object budget as a node: the 1 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• credential (object)↗: The object credential as a node: the 4 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• file (object)↗: The object file as a node: the 5 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• message (object)↗: The object message as a node: the 2 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• network-endpoint (object)↗: The object network-endpoint as a node: the 2 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• process (object)↗: The object process as a node: the 2 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• record (object)↗: The object record as a node: the 3 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• repository (object)↗: The object repository as a node: the 2 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• schedule (object)↗: The object schedule as a node: the 2 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• host (reach)↗: The reach host as a node: the 8 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• project (reach)↗: The reach project as a node: the 3 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• self (reach)↗: The reach self as a node: the 2 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• tenant (reach)↗: The reach tenant as a node: the 7 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• world (reach)↗: The reach world as a node: the 3 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• browser (family)↗: The family browser as a node: the 1 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• code (family)↗: The family code as a node: the 4 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• communication (family)↗: The family communication as a node: the 2 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• filesystem (family)↗: The family filesystem as a node: the 6 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• identity (family)↗: The family identity as a node: the 3 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• money (family)↗: The family money as a node: the 1 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• network (family)↗: The family network as a node: the 2 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• process (family)↗: The family process as a node: the 2 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• schedule (family)↗: The family schedule as a node: the 2 capability primitives it appears in, what they reach, and how it connects. Meaning from connectivity, not from a definition.
• The edge vocabulary↗: The 22 edges this model is written in, each a verb with a distinct inverse, a stated domain and range, and the sentence it reads as.
• The node type formulas↗: A node type is a required pattern of typed, directed paths that a node either matches or does not. Not a label somebody applied. Run against the graph on every build.
• The three layers↗: How a customer vault extends this vocabulary without merging anything: shared facts owned by nobody, per-party formulas, and declared bridges. Parties can disagree about meaning while still agreeing about facts.
• The universes↗: The ABP mapped onto Fractal Semantic Graphs: one capability row walked through nine universes, from the source bytes to a licence condition, each with its own owner and ontology, joined by named edges. Four more named as gaps.
• U0: The source bytes↗: The source bytes, one of the universes an ABP row crosses: owned by nobody: the bytes are what they are, with its own node types and verbs, sharing only the grammar. Status: partial.
• U1: The grammar↗: The grammar, one of the universes an ABP row crosses: owned by abp.sgit.ai, promoted from what-can-it-do.games.sgit.ai and bridged back to it, with its own node types and verbs, sharing only the grammar. Status: live.
• U2: The deployment shape↗: The deployment shape, one of the universes an ABP row crosses: owned by the vendor's published words, read on a date, with a hash, and never probed, with its own node types and verbs, sharing only the grammar. Status: partial.
• U3: The grant and its evidence↗: The grant and its evidence, one of the universes an ABP row crosses: owned by whoever observed, or the documentation that was read, with its own node types and verbs, sharing only the grammar. Status: one-edge.
• U4: The enforcement↗: The enforcement, one of the universes an ABP row crosses: owned by whoever set the control: the vendor, the platform, the deployer or nobody, with its own node types and verbs, sharing only the grammar. Status: one-edge.
• U5: The deployer↗: The deployer, one of the universes an ABP row crosses: owned by the deployer, in their own words, and the named person who will correct the draft, with its own node types and verbs, sharing only the grammar. Status: partial.
• U6: The derivation↗: The derivation, one of the universes an ABP row crosses: owned by the computation, and never a person, with its own node types and verbs, sharing only the grammar. Status: partial.
• U7: The projections↗: The projections, one of the universes an ABP row crosses: owned by the renderer, and the fact diff that has to check it, with its own node types and verbs, sharing only the grammar. Status: partial.
• U8: The licence, the acceptance and the risk↗: The licence, the acceptance and the risk, one of the universes an ABP row crosses: owned by riskmandate.ai, with its own node types and verbs, sharing only the grammar. Status: outside.
• U9: The estate and the twin↗: The estate and the twin, one of the universes an ABP row crosses: owned by the customer, through twins.sgit.ai, with its own node types and verbs, sharing only the grammar. Status: partial.
• U10: The obligations↗: The obligations, one of the universes an ABP row crosses: owned by standards.sgit.ai and the AIUC-1 conformance vault, with its own node types and verbs, sharing only the grammar. Status: gap.
• U11: The runtime↗: The runtime, one of the universes an ABP row crosses: owned by whoever holds the logs: never this site, with its own node types and verbs, sharing only the grammar. Status: gap.
• U12: The estate of agents↗: The estate of agents, one of the universes an ABP row crosses: owned by the organisation, with its own node types and verbs, sharing only the grammar. Status: gap.
• Your mailbox, and what you gave it↗: Four steps and thirteen prompts you paste into your own assistant, to find out what connecting it to your mailbox actually gave it, what you meant to give it, and how much of the difference you can write down.
• The measured deployment: what the agent that holds the connector found↗: One mailbox, one Gmail connector, thirty tools measured from their own schemas by the agent holding them, and the four objects it wrote. The first shape on this site measured end to end by the thing being profiled, and the ratchet between an authored mandate and an inferred one, as a number.
• Step 1: what it can already do↗: Four prompts that make your own assistant enumerate its mailbox tools, what each one reaches, which of them you could undo, and which lines it is inferring rather than reading.
• Step 2: what you actually asked for↗: Three prompts that make the assistant draft your mandate over its own tools in three lists, describe your mailbox as you actually use it, and derive the gap. Correcting the draft is the exercise.
• Step 3: write the behaviour policy↗: Four prompts that turn the gap into a document you can keep: four lines to paste anywhere, a full clause set, the same thing in the four object shape, and the layer your organisation owns rather than you.
• Step 4: what a prompt cannot do↗: The document you wrote in step three is an expectation rather than a control. Why that is the honest reading, why it is still worth writing, and what would actually bound the behaviour.
• The cost ABP: how much, not just what↗: An Agent Behaviour Policy over how much an agent may spend: tokens, files, commits, fetches and other people's time. Four steps and twelve prompts, for a deployer watching the bill, the repository and the review queue all grow.
• Step 1: what it has already spent↗: Three prompts that make the agent count what it can count in the current session, sort it into asked for and decided, and name the numbers it cannot see.
• Step 2: what you actually paid for↗: Two prompts that turn the ledger into a cost mandate: what you want spent freely, what should be batched or asked about, what must never be spent, and what waste means for you in particular.
• Step 3: write the cost policy↗: Four prompts: four lines, the full clause set with limits per turn and a research rule, the ledger clause, and the accountant, a second agent whose only job is to read the ledger against the clauses.
• Step 4: what a clause over a count cannot do↗: A limit the agent cannot measure is an expectation twice over. Which of the four barriers a turn cap, a spend limit and a pipeline budget actually are, who can turn each one off, and what the ledger is and is not.
• An assistant on your own machine↗: Four steps and ten prompts for somebody running an assistant as their own user account on their own machine, with local files, commands, connectors and past conversations in reach. The same sequence as the mailbox and cost walkthroughs.
• Step 1: what it can reach on your machine↗: Three prompts that make the desktop assistant list its local tools, connectors and past conversations, say which are switched on, and name what it cannot see about its own reach.
• Step 2: what matters, and what does not↗: Three prompts that produce the map of the machine in the person's words: the work, the not-yours, the credentials, the record, and what in it must never be reused.
• Step 3: write the rules↗: Two prompts: four lines, and the full rule set that opens with the map rather than with prohibitions, and ends with a report at the end of every turn.
• Step 4: what a switch is, and is not↗: Four of the shape's rows sit at a setting the account can flip. Why a switch you can turn off is not a control, what on a machine actually is one, and the two prompts that grade the rules and name the caps.
• Cases↗: One person's estate of deployments, each an Agent Behaviour Policy, elicited from them rather than authored. What this site holds in the estate universe.
• Case beta-001: One person, two assistants, six deployments, one shared account↗: One business user, two chat assistants, six deployments over five connectors, four of them sharing one Google account. The estate mapped, the mandates elicited, the grants not yet measured.
• Case beta-001: ChatGPT with the Gmail connector, allow all↗: The elicited mandate, the clauses and the discovery prompt for ChatGPT with the Gmail connector, allow all, with the nearest published shape standing in for a grant that has not been measured.
• Case beta-001: ChatGPT with the Google Calendar connector, allow all↗: The elicited mandate, the clauses and the discovery prompt for ChatGPT with the Google Calendar connector, allow all, with the nearest published shape standing in for a grant that has not been measured.
• Case beta-001: ChatGPT with the Google Drive connector, allow all↗: The elicited mandate, the clauses and the discovery prompt for ChatGPT with the Google Drive connector, allow all, with the nearest published shape standing in for a grant that has not been measured.
• Case beta-001: ChatGPT with a meeting note taker connected↗: The elicited mandate, the clauses and the discovery prompt for ChatGPT with a meeting note taker connected, with the nearest published shape standing in for a grant that has not been measured.
• Case beta-001: The inbox scout: the same Gmail grant, running with nobody present↗: The elicited mandate, the clauses and the discovery prompt for The inbox scout: the same Gmail grant, running with nobody present, with the nearest published shape standing in for a grant that has not been measured.
• Case beta-001: Claude with the Slack connector↗: The elicited mandate, the clauses and the discovery prompt for Claude with the Slack connector, with the nearest published shape standing in for a grant that has not been measured.
• Case session-001: The session that built this site's last twelve releases, as a ledger↗: The session that built releases v0.4.0 to v0.8.1 of this site, as a case: the measured shape it ran on, the mandate from the deployer's messages, and a ledger of what it spent, counted from the repository where it could be.
• Case session-001: Claude Code on the web, one repository attached: the session that built v0.4.0 to v0.8.1↗: The elicited mandate, the clauses and the discovery prompt for Claude Code on the web, one repository attached: the session that built v0.4.0 to v0.8.1, against the published shape this deployment is.
• Case estate-002: One person, three surfaces of one product, one account holding every past conversation↗: A deployer who runs one assistant in the browser, as a coding agent and as a desktop work product, over one account that holds every past conversation. The mandates elicited around one rule: reading the past is on demand.
• Case estate-002: Claude in the browser, with connectors possibly still on↗: The elicited mandate, the clauses and the discovery prompt for Claude in the browser, with connectors possibly still on, with the nearest published shape standing in for a grant that has not been measured.
• Case estate-002: Claude Code, in a container with a repository attached↗: The elicited mandate, the clauses and the discovery prompt for Claude Code, in a container with a repository attached, with the nearest published shape standing in for a grant that has not been measured.
• Case estate-002: Claude Cowork, on the desktop↗: The elicited mandate, the clauses and the discovery prompt for Claude Cowork, on the desktop, with the nearest published shape standing in for a grant that has not been measured.
• The articles↗: One article per release, explaining what changed and why, with the screenshots taken from the tag each one names and diagrams of the mechanisms a screenshot cannot show.
• v0.1.0: The ontology already existed, so the first release promoted it instead of writing one↗: Twenty three capability primitives, nine deployment shapes and four barriers were already published as the data pack a game reads. The first release gave them an address and derived five worked ABPs from them, and the thing that took the time was the honesty line rather than the research.
• v0.2.0: A rule this site published in the morning was wrong by the afternoon, and the correction is on the page↗: The foundation document says twice that the delta is computed and never stored. Half of that was right. The corrected rule is harder, the passages were not rewritten, and the check that enforced the old rule was inverted to enforce the new one.
• v0.3.0: read.file.project was a string with a gloss beside it, which is schema-first thinking in graph syntax↗: Thirty three words that existed only as substrings got a node, a file and a page each. A node type stopped being a label and became a formula the build walks. And the reach pages started keeping nine disagreeing definitions of one word instead of averaging them.
• v0.4.0: An ABP is a junction object, which is what Fractal Semantic Graphs is for↗: Applying the zoom test to this site's own graph returns an uncomfortable answer: it decomposes one vocabulary very well and crosses into another in exactly two places. The map names the nine worlds one capability row actually crosses, and who owns each.
• v0.4.1: The map became files, pages and a gate check, and the walk is rebuilt on every build↗: A map in prose is a claim. Thirteen universes as data with a page each, a walk computed from the published rows, and a fourteenth check that refuses to publish a world nobody owns. The walk immediately found an error in the brief that drew it.
• v0.4.2: The fact diff was named as a blocker on four consecutive days, and it reads the published page↗: Every projection renders the same fact set with an empty diff. That rule had no mechanism behind it for a month. The mechanism parses the label, the leaflet, the prohibitions and the figure back out of the page that shipped, because a diff that trusts the generator checks nothing.
• v0.4.3: The home page has argued about one setting since v0.1.0, and now the build walks it↗: A product, a tool and a setting became node types with formulas, derived from data the site already held. The setting that distinguishes confirmations on from confirmations off was found by diffing two grants, and whose material a capability reaches was declared without being guessed.
• v0.4.4: Seven deployment shapes somebody else measured, promoted with their provenance intact↗: A consumer of this data built seven shapes this site did not have, one of them from a dated probe of a live instance. Under the three layers those are facts owned by nobody, so they belong at the address every consumer reads. The bytes are held unchanged and the evidence tier stays the contributor's.
• v0.5.0: The releases get one article each, and the screenshots come from the tag rather than from today's site↗: A release record says what changed and is deliberately terse. Nothing said why. This release adds the section you are reading, and the rule that makes it worth reading: a figure about the eleventh of September shows the site as it stood on the eleventh of September, version badge and all.
• v0.6.0: Thirteen prompts a reader runs against their own mailbox, and the fourth page that says what a prompt cannot do↗: Every page before this one was written for somebody who already believes the argument. This release adds the door: a walkthrough that does not hand a reader a table, because the agent in front of them can produce a better one for their own deployment. And the page that keeps it honest, which is the one that says the document they just wrote is not a control.
• v0.7.0: The first case: one person's estate, the mandates elicited line by line, and the grants left empty on purpose↗: Every shape on this site is a vendor's product in a configuration. A case is one person, the assistants they actually run and the connectors they actually switched on, with a mandate for each in their own words. The first one has two assistants, six deployments and one account four of them share, and it starts with the mandate side full and the grant side empty, which is the opposite of a shape.
• v0.8.0: The cost ABP: every ABP so far bounded what, and this one bounds how much↗: Cost is not a capability. It is a property of every call, the grammar has one primitive for money and none for a count, and quantity lives in the one universe this site has no node in. So the release says that first, then puts the substance where it can live: twelve prompts, a ledger every turn, and an accountant to read it.
• v0.9.0: Two more cases: this site's own session as a ledger, and three surfaces of one product over a record that contains secrets↗: The cost walkthrough said no case had run its prompts. The first case here is that case, on the one shape whose grant was measured, with a ledger counted from the repository and the workflow log. The second is a deployer with one assistant on three surfaces and one rule: reading the past is on demand.
• v0.10.0: The desktop walkthrough: on your own machine, host means your machine, and the mandate is a map of what matters before it is a list of rules↗: The third walkthrough in the same four steps, because the workflow is meant to always be the same. On a machine the published shape's character is that reading files, changing them and running commands each sit at a switch the account can flip. The concept the section is built on is the deployer's: what is being given to the agent is context on what is important and what is not.
• Agent Behaviour Policy (ABP): You Know What You Asked For, And You Do Not Know What It Can Do↗: version v0.33.70 date 11 September 2026 from Dinis Cruz to Anyone deploying an agent, anyone building one, and anyone who has to sign for one
• The Behaviour Policy Is A Graph And Every Document Is A Projection: The W3C Has The Vocabulary, And A Prohibition Has Two Lives↗: version v0.33.70 date 11 September 2026 from Human (project lead) to Whoever models the graph, whoever builds the renderer, and whoever compiles the prohibitions into something that enforces them
• The Delta Is Derived And Never Authored: Storing It Is The Point, And The History Is The Business Case↗: version v0.33.70 date 11 September 2026 from Human (project lead) to Whoever builds the ABP data model, whoever wires the recompute, and whoever has to correct a document that is already published
• The Behaviour Policy Is The Document The Only Agent Insurer Already Requires: Sell The Correction, And Not The Draft↗: version v0.33.70 date 11 September 2026 from Human (project lead) to Whoever names the product, prices it, and stands at the table with it next week
• The Prohibitions Are The Exclusions: Your Own Demo Says No Policy Covers The Delta, And The Insurance Act Says How↗: version v0.33.70 date 11 September 2026 from Human (project lead) to Whoever plans the ladder from the behaviour policy to everything above it, and whoever talks to an underwriter first
• No Gmail Scope Lets An Agent Draft Without Letting It Send: The Drafts Have To Leave The Mailbox, And The Trifecta Is Broken By Credential Rather Than By Classifier↗: version v0.33.71 date 20 September 2026 from Human (project lead) to Architecture, the Agent Behaviour Policy team, whoever builds the inbound pipeline for the published address, and legal
• The Behaviour Policy Is Already A Fractal And The Overlay Is Already Published: The Customer Authors Formulas And Bridges And Never Deltas, And The Barrier Weakens With Every Layer Above The Platform↗: version v0.33.71 date 20 September 2026 from Human (project lead) to Architecture, the Agent Behaviour Policy team, the owners of abp.sgit.ai, graphs.sgit.ai and standards.sgit.ai, whoever builds the indexes
• The Split Does Not Break The Trifecta, The Schema Does: A Closed Vocabulary At The Boundary Is The Control, And The Orchestrator Should Not Hold The Mailbox↗: version v0.33.71 date 20 September 2026 from Human (project lead) to Architecture, the Agent Behaviour Policy team, whoever writes the command line tool and the vault application
• The Transition Demotes An Imperative To A Proposition: The Ontology Bounds The Space And Never The Choice, And A Requested Action Is Not An Authorised One↗: version v0.33.71 date 20 September 2026 from Human (project lead) to Architecture, the Agent Behaviour Policy team, the graph grammar owners, whoever builds the extraction stage
• The Twin Of The Interface Is The Grant In Machine Readable Form: Three Twins Are Needed Rather Than One, And The Mandate Check Becomes A Traversal Between Them↗: version v0.33.71 date 20 September 2026 from Human (project lead) to Architecture, the Agent Behaviour Policy team, and whoever builds the first mailbox vault
• Marking Everything Read Destroys This User And Breaks Nothing: The Grant Cannot Tell Filing From Erasing A Task List, And The Control Is A Snapshot Rather Than A Prompt↗: version v0.33.71 date 19 September 2026 from Human (project lead) to Strategy, the Agent Behaviour Policy team, the RiskMandate product owner, whoever takes the skills site
• The Consent Dialog Is An Accountability Transfer Rather Than A Decision: The User Is Asked At The Moment They Know Least, And The Irreversible Gmail Action Sits In Google's Least Guarded Tier↗: version v0.33.71 date 19 September 2026 from Human (project lead) to Strategy, the Agent Behaviour Policy team, the RiskMandate product owner, whoever builds the first grant viewer
• The ABP Is A Fractal Semantic Graph: One Row Crosses Nine Universes, Each Keeps Its Own Ontology, And The Ladder Runs Up To The Estate Of Agents↗: version v0.4.0 date 20 September 2026 from The site's agent, for the project lead to Whoever models the ABP graph, whoever builds the pages of abp.sgit.ai, and the teams at riskmandate.ai and store.sgit.ai who render against its data
• Start Here↗: You are building abp.sgit.ai, the site for the Agent Behaviour Policy. This pack is what has been decided, what already exists, and what you must not invent.
• What To Build↗: Every site in the network is named for an argument rather than for a function, and there are twenty seven of them. The argument here is not a product name.
• The Conventions↗: Three sources govern how this site is built. Read all three before writing code. Where this pack and a source disagree, the source wins and you should say so.
• The ABP Model↗: The ABP describes. It does not judge. It states what the agent can do, what it was authorised to do, the gap between them, and what stands in the way. It says nothing about whether any of that is acceptable, because acceptability is not in...
• The First Examples↗: The memo asks for a few ABPs, from simple to complex, to find out what they look like in practice and how hard they are to make. The answer is that the first five can be derived rather than authored, because the data exists.
• The Hard Rules↗: Thirteen rules that constrain this site. Each has a source and a reason. Rule 0 sits above the others and rules 1 and 13 are the two most likely to be broken.
• The Prompt↗: Paste this to the agent that builds the site. It is the standard prompt for a new network site, extended with what this one needs.
• An External Review Of Fractal Semantic Graphs Against The Prior Work: Distributed Logics, Named Graphs, Ontology Alignment, Federation And Provenance↗: date 20 September 2026 from A review produced by ChatGPT at the project lead's request, on the Fractal Semantic Graphs page at sgit.ai and its supporting vaults, and handed to this site for the record to Whoever builds the universes on...
• Docs↗: Every reference and guidance document behind this site, rendered, with a link to the source bytes of each. The index is generated from the files present.
• v0.11.0: the Gmail connector measured end to end by the agent that holds it, read from a vault, mapped into the grammar, and set beside the profile read from the vendors' pages↗: On 19 September the agent operating a mailbox through the Gmail connector read its own thirty tool schemas, checked them against the live permission page, sent mail with no prompt, relabelled sixteen messages in nineteen unprompted writes, hit one refusal it could not explain,...
• v0.10.1: the desktop walkthrough gets its article, with six figures captured from the v0.10.0 tag↗: One article per release, so the release that added the desktop walkthrough gets one. It covers why the third walkthrough keeps the shape of the first two, why the switch is the character of the desktop shape, why the map of what matters comes before the rules and why every rule...
• v0.10.0: the desktop walkthrough: an assistant on your own machine, the map of what matters on it, and the rules that open with the map; plus the article for v0.9.0↗: The third walkthrough, in the same four steps as the mailbox and cost ones because the deployer asked for the workflow to always be the same: find out what is going on, then write the rules that let the agent decide better for itself. On a machine the word host means the...
• v0.9.0: two more cases: the session that built this site, as a ledger with a measured grant, and one person's three surfaces of one product over an account that holds every past conversation↗: The cost walkthrough shipped with the line that no case ran its prompts yet. The first case in this release is that case: the session that built releases v0.4.0 to v0.8.1, on the one shape this site holds whose grant was measured by the thing being profiled, with a ledger of...
• v0.8.1: the cost ABP gets its article, with six figures captured from the v0.8.0 tag↗: One article per release, so the release that added the cost walkthrough gets one. It covers why cost is a property of every call rather than a capability, why the section is written over the runtime universe and says so on every page, why the fifth cost line is the reason the...
• v0.8.0: the cost ABP: a walkthrough over how much an agent may spend rather than what it may do, with a ledger every turn and an accountant to read it↗: Every ABP on this site bounds what an agent may do. This release adds the one that bounds how much: tokens, files written, commits pushed, fetches run, and the hour of somebody else's time an agent spends by asking a question or handing over something to read. Cost is not a...
• v0.7.1: the first case gets its article, with six figures captured from the v0.7.0 tag↗: One article per release, so the release that added the case gets one. It covers why a case is the person's object where a shape is the vendor's, why the account is the node where the two levels meet, why every elicited line carries a said or inferred mark, why the grant side is...
• v0.7.0: the first case: one person's estate of six deployments, the mandates elicited from an interview line by line, and the grants not yet measured↗: Every shape on this site is a vendor's product in a configuration. This release adds the object one level up: a case, which is one person, the assistants they actually run, the connectors they actually switched on, and a mandate for each elicited in their own words. The first...
• v0.6.1: the mailbox walkthrough gets its article, with six figures captured from the v0.6.0 tag↗: One article per release is the rule, so the release that added the walkthrough gets one. It covers why a section aimed at somebody who does not yet believe the argument had to be prompts rather than a table, why the prompt became a block in the vocabulary rather than raw markup...
• v0.6.0: a walkthrough for somebody who has connected an assistant to their own mailbox: four pages, thirteen prompts, and a fourth page that says what a prompt cannot do↗: Everything on this site so far was written for a reader who already believes the argument. This release adds the door: a section at /gmail/ for somebody who connected an assistant to their mail, has never seen the list of what that gave it, and can be handed one link. It does...
• v0.5.1: the articles run newest first, carry their version in the title, and link to the release before and after them↗: Four changes to the section added yesterday, all of them about making the sequence readable. The index lists the newest release first, because that is what a reader arriving at it wants, while the register underneath stays in release order because that is the order the older and...
• v0.5.0: the releases get one article each, with the screenshots taken from the tag each one names rather than from today's site↗: The version surface says what changed, in the release's own words, and it is deliberately terse. Nothing on this site said why. This release adds an articles section: one article per release from v0.1.0 to v0.4.4, each explaining what the release changed, what it cost, and what...
• v0.4.4: seven shapes contributed by riskmandate.ai are promoted with their provenance, a vendor scope becomes a node, and the intake path is the same for anybody↗: The second of the three requests riskmandate.ai published against this site on 12 September, the one it marked as unblocking a product. Seven deployment shapes it built ahead of this site, two Gmail scopes, a Drive scope, a Microsoft 365 connector, a Dropbox server, the Google...
• v0.4.3: the product, the tool and the setting become nodes, derived from data already published, and whose material is declared on the grammar↗: The deployment shape universe, as far as published data takes it. A shape used to carry its tools as strings and nothing about what distinguishes one variant of a product from another. Now a product is a node with its variants, every tool a shape runs with is a node that exposes...
• v0.4.2: the fact set is data, the fact diff runs over every published page, and every example ends by crossing nine universes↗: The projections universe, one release after the map named it. Every projection renders the same fact set and the diff must be empty: a rule in force since August that blocked a promise on four consecutive days in September because the diff did not exist. It exists now, in the...
• v0.4.1: the universes become data with a page each, the walk of one row is built on every build, and the gate checks that every node type is owned↗: The map of v0.4.0 becomes files the build reads, pages that render one query, and a gate check. Thirteen universes are authored in admin/build/universes.py, each with its owner, its centre of gravity, its smallest node, its status, its node types and its verbs; the build writes...
• v0.4.0: the ABP is mapped onto Fractal Semantic Graphs: one row crosses nine universes and each keeps its own ontology↗: A map, and nothing built from it yet. By the zoom test as graphs.sgit.ai now states it, the graph this site holds at v0.3.0 decomposes one vocabulary very well and crosses into another in exactly two places, the reach class disagreement and the bridge to the game. An ABP is a...
• v0.3.0: read, file and project become nodes with their own addresses, and a node type stops being a label and becomes a formula↗: The model pages were a projection of nothing. A capability was an identifier with a gloss beside it, which is a self-describing node, which is schema-first thinking dressed in graph syntax: the meaning was attached to the node rather than derived from its edges. This release...
• v0.2.0: the delta is derived and never authored, so it is stored with its inputs pinned and the gate recomputes it↗: A correction to a rule this site published nine hours earlier, applied in the open. The foundation document says, twice, that the delta is computed and never stored. The first half is right and the second half is wrong: the delta is stored, and storing it is most of what makes...
• v0.1.0: the ontology is promoted out of a game and the five examples are derived rather than written↗: The first version of abp.sgit.ai. The capability ontology the ABP needs already existed, published, as the data pack a game reads, so this release promotes it into a schema with a stable address rather than authoring a second one, and derives five worked ABPs from it. Nothing on...
• Versions↗: Every release of this site, with the commit it was built from and what it was built against. The version in the chrome links here.

Data

• The published vocabulary↗: the capabilities, barriers, undo classes, deployment shapes and mandates an ABP is written in, at stable addresses with cross origin access.
• Provenance↗: where every row came from, and how many were measured.

Release history

• v0.11.0↗ (2026-09-22) the Gmail connector measured end to end by the agent that holds it, read from a vault, mapped into the grammar, and set beside the profile read from the vendors' pages
• v0.10.1↗ (2026-09-22) the desktop walkthrough gets its article, with six figures captured from the v0.10.0 tag
• v0.10.0↗ (2026-09-22) the desktop walkthrough: an assistant on your own machine, the map of what matters on it, and the rules that open with the map; plus the article for v0.9.0
• v0.9.0↗ (2026-09-22) two more cases: the session that built this site, as a ledger with a measured grant, and one person's three surfaces of one product over an account that holds every past conversation
• v0.8.1↗ (2026-09-22) the cost ABP gets its article, with six figures captured from the v0.8.0 tag
• v0.8.0↗ (2026-09-22) the cost ABP: a walkthrough over how much an agent may spend rather than what it may do, with a ledger every turn and an accountant to read it
• v0.7.1↗ (2026-09-21) the first case gets its article, with six figures captured from the v0.7.0 tag
• v0.7.0↗ (2026-09-21) the first case: one person's estate of six deployments, the mandates elicited from an interview line by line, and the grants not yet measured
• v0.6.1↗ (2026-09-21) the mailbox walkthrough gets its article, with six figures captured from the v0.6.0 tag
• v0.6.0↗ (2026-09-21) a walkthrough for somebody who has connected an assistant to their own mailbox: four pages, thirteen prompts, and a fourth page that says what a prompt cannot do
• v0.5.1↗ (2026-09-21) the articles run newest first, carry their version in the title, and link to the release before and after them
• v0.5.0↗ (2026-09-20) the releases get one article each, with the screenshots taken from the tag each one names rather than from today's site