Versions and changelog

Versions#

The specification is published one version at a time. This site carries 0.27.0-draft, dated 2026-10-17, and every page of the specification names that version at the top. The table lists each version with the date in its changelog entry and the first words of that entry.

The source of every version is in the Common Agent Standards repository, where each version from 0.26.0-draft on is tagged as common-agent-v followed by the version. A tagged version is also kept at an address of its own: 0.27.0-draft, 0.26.0-draft. The main branch, which can be ahead of the published version, is rendered at commonagent.net/draft/.

Changelog#

The changelog is part of the specification's source and is reproduced here in full, newest first.

1. 0.27.0-draft (2026-10-17)whom an agent acts for, what an offering may be asked, and what it can touch. Section 6.2 gains acts_for, REQUIRED in a bound Descriptor: person, a personal agent, the same thing Section 7.8 and PACT call one; organization, a business or team agent, which MAY name the organization in organization_name; and anyone, a public service with no principal. It is decided at install, so a draft carries none, and a Descriptor without it, including every one written before this version, is read as not stated and never guessed. Section 6.9 ties it to the consent rules: a connection of the door (Section 7.1) is offered only between agents that act for a person, and where the other side's acts_for is not stated the person deciding is shown so; only an agent that acts for a person acts on a person's grants, and a business's agent behind a PACT Provider declares organization; and the person behind an agent who reads messages marked for a person (Agent Messaging, Section 5.7) is its owner, whoever the organization names, or nobody for an agent that acts for anyone. Sections 7.1 and 7.8 cite it. interaction is narrowed to one question, whether a person is attending the agent right now, and Section 9.5 no longer calls it the service-or-personal axis; its caller-side semantics are cited to Section 6.9, where they are. Section 6.11 gives each offering a scope. task-specific is named work with typed inputs and outputs, and it is what an offering without scope means, so every existing Descriptor stays valid. open-with-focus takes any instruction within a stated focus and declares its focus, one of software, documents, data, research and operations, with a role from the Agent Roles registry recommended; its workspace[], the shared resources of Section 5.3 it works in, as shapes; its authority; its deliverables in outputs[]; and its ceilings. open-ended takes any instruction, declares its authority and ceilings, has its agent declare data use, and makes no claim about what it can do. An unrecognised scope reads as open-ended. One agent may mix scopes, and any agent-level summary is derived from its offerings. authority is a closed list of what an offering can touch: reads-files, writes-files, reads-systems, updates-systems, triggers-systems, runs-commands, reaches-network, sends-messages and spends-money, built on resource access, systems[] access levels and the connection grants, with authority_decided_by saying what keeps a running job inside it. ceilings bound one job (job_seconds, cost_per_job, spend_per_job, messages_per_job), each as { most, decided_by }, and an install may lower them and never raise them; the Descriptor's limits may take the same form. Section 4.6 keeps the rule that there is no default route: an open offering is still a named offering that a request names, and the boundary checks, by rule and in order, the offering, the workspace, the authority the request allows (a request may narrow it with authority, and one that allows spends-money carries spend_limit), and the budget. The refusal is SCOPE_REFUSED, with reason workspace, authority, spend_limit or focus. Section 4.7 has every refusal carry decided_by, rule, model or person, so a reader knows whether code enforced it or a model judged it; "that is outside my focus" is decided by the model, and a refusal without the member is read as not stated. Testing follows scope. A task-specific offering is tested case by case as before; an open-with-focus offering against an evaluation set for its focus, which Section 8.4's evaluation record now names in evaluation_set with its result; and an open-ended offering only on its limits, with no capability case allowed. The record gains offering and scope, and its refusal cases record decided_by. Directories do not match open-ended offerings by a search for the work wanted. The AgentDoc's sells carries every offering's scope, derives sells.scopes, labels open offerings in words, does not present what an offering will try as what it can do, and shows a ceiling as enforced only when a rule decides it and visibility allows. Sections 9.8 and 9.10 gain the matching rendering rule and checks. A new fixture, conformance/offering-scope.json, pins the declaration checks, the boundary cases, the decided_by of each refusal, the mapping below, and the directory rule. Section 6.12 takes the Descriptor's shape apart, because it described the agent's inside and this specification describes the outside. kind is removed, and decided_by answers its real question; a deployment record may still say what was installed, as background, in the new optional installed (Section 8.3), and Section 9.5.1 loses the kind table and keeps visibility. memory moves into data use beside retention (Section 6.9) as remembers-across-jobs or starts-clean-each-job. model maps to data use processors. steps is replaced by scope and tools_runtime by authority, and neither maps to a value, since each was a fact about the inside. fleet becomes a member at the level of the agent's identity, and the AgentDoc carries it and acts_for in identity. harness stays in deployment records only, in target. For this revision readers accept the old members and map them as Section 6.12's table says, and writers emit the new ones; the old members are removed in 0.28.0-draft. The AgentDoc's shape section keeps its name and now carries interaction and visibility. In the package chapter, a draft carries each offering's scope, authority and ceilings and no acts_for (Sections 12.3 and 12.6, rule 4), the install decides acts_for, interaction and fleet and may lower ceilings (rule 6), and Section 12.10 checks the new members. The floor. Section 4's opening now says that every requirement in it applies to every agent, and that an optional capability, with the rules that come with choosing it, lives in Section 7. The encryption key, which sat in Section 4.1 as an optional capability inside the floor, moves to Section 7.2 with sealing: the X25519 key distinct from the signing key, the signed key claim required wherever one is declared, cleartext only where none is, and where sealing ends. Section 4.1 keeps one sentence that points there, and Sections 6.9 and 10 and Appendix A follow.
2. 0.26.0-draft (2026-10-08)run configs, the manifest. Section 5.8 says the job manifest's run_config is the manifest's own member, once, never a piece's; that its values are written plainly as the job's part carried them, with the layers on the run record (Section 8.7) rather than in the manifest; and that a reader of a manifest made before the member existed may read the name and resolved digest from a piece's produced_from entry run-config:<name>@<resolved>.
3. 0.25.0-draft (2026-10-07)run configs, third part. Section 12.7 gains Install alongside, another version of an installed package under the same subject, with its own install settings, reached only by a job that names it while the bound Descriptor stays the current version's, and Retire a version, which never takes the current one. Section 5.8's version check lets a job go ahead on a version installed alongside, has the job manifest name the version that did the work, and has the agent's node refuse a job from a named run config that names a version it does not hold. Section 8.3's act gains alongside and retire-version.
4. 0.24.0-draft (2026-10-07)run configs, second part. Section 5.8 gains teams (a member is in at most one team of an organization, and that team's layer is theirs there); locks by an organization or a team, which hold the value a setting has after that layer and refuse a closer layer's other value with the new reason locked; run configs kept by an organization, a team or a person, applied at that layer, optionally based_on the solution's run config, chosen by name closest keeper first, and adopted for a team or an organization by its leads or admins; moving a pin after a replay, made by the mover's side where the agent declares replay: true and described by the mover where it does not, with a replay report kept with the move; and telling a run config's keeper what a change above means for it (picked up, kept, or its next run would stop), before the next run. Section 6.2's run_config block gains replay. Section 8.7 writes locked_by beside locked and says which layer a kept run config's values carry.
5. 0.23.0-draft (2026-10-07)run configs. Section 5.8 defines the run config, a named, versioned set of choices a job runs under (the version of each agent, the model, and the settings that shape the output), and keeps it apart from an agent's install settings, which no run config reaches. The document, "run_config": "v1" (name, scope, process_digest, steps with agent, version, package_digest, model, settings and the optional newer_patch, platform, answers, and a JCS digest); six layers from the author to the run, where a preference takes the closest value and a rule the tightest, narrowed and never widened, with organization locks; the resolved run config and its digest over plain values; a sender who does not own the agent setting only job_may_set settings inside the owner's rules, which the agent's side applies; the step's part handed over as the run_config member of a run context "v2"; the agent's duty to use every value exactly or refuse with RUN_CONFIG_REFUSED (not_declared, not_settable, not_allowed, cannot_use, version_mismatch), never substituting; and the version check before the first step. Section 5.7's job manifest gains run_config. Section 6.2 gains the Descriptor member run_config: declared settings with kind, default, allowed and job_may_set, tested_models, and the author's named run configs with digests. Section 8.7 puts the resolved run config on the run record, with the layer each value came from and the version checks. Section 9.5 gains the configs section, which says which models are untested. Section 12.3 lets a package ship named run configs, and 12.7 and 12.10 have the depot check them against the declared settings.
6. 0.22.0-draft (2026-10-06)acting for a person at a business. Section 7.8 adopts PACT 1.0 (https://openpactprotocol.org/spec.md) for an agent acting for its person at a business's agent over A2A: PACT Identity required on both sides, PACT Delegated where the business offers it, and a personal agent never collects the person's credentials for a business account. A personal agent SHOULD send a different sub for one person to each Provider. An offering MAY carry scopes, a list of {id, description}, and the union over a business's offerings is the scope list on its PACT card. Inside a delegated turn the agent acts only within the grant, answers auth required for a missing scope, and lists the scopes it used and the acts it did for the receipt. A table sets this specification's terms beside PACT's: a connection's grant beside a PACT grant, a task's receipt and the record of who asked beside pact.receipt, and the owner's OK beside auth required. What PACT leaves here is stated: spending, ending a grant from the person's side, offline and late replies, and connections between two people, all four offered to PACT's working group as proposals. Section 7.1's connections gain a line saying a business is not a connection. Two conformance fixtures, pact-identity and pact-delegated.
7. 0.21.0-draft (2026-10-05)trials. Section 7.7 says how an agent is tried before anyone pays: an offering's trial declaration (who, a shape of tighter input limits, omitted outputs, live_seconds, keeps_days and a mark, and limits as counts only); the trial: true request marker, never with a budget; admission by the node in a fixed order with the refusal TRIAL_REFUSED (reason, limit, resets_at, quote); the allowance's new trial scope, so the publisher funds trials inside a ceiling that paying requesters' headroom never covers; live sessions on trial deliverables and samples counted as trial work; the trial receipt that rates to zero; samples, published in agent-samples-v1 through the Descriptor's new samples_ref, each tied to the receipt of the task that made it and shown as confirmed, earlier, or stated; solutions, whose trial is the prime's, paying its parts as ordinary work under its engagements; hosts that vouch for visitors and enforce the counts; and three conformance cases. Section 9.5's sells section carries the trial and the samples. Also in 0.21.0-draft, connections. Section 7.1 gains connections, mutual scoped admission two people agree to: four enumerated grant names (messages, scheduling, share, errands) read from what a message carries and never from its words; an Errands spend limit with the owner's yes to each order; the narrowing rule (accept or narrow, never widen); an end date after which the entry is absent; revocation by either side, immediate on both; a stop control that overrides every connection; and matching words on both screens when two people connect in person. The knock MAY carry enumerated grant names and nothing else; a knock carrying prose is refused whole. Bound on AgentMesh by EXT-6 0.4.0 and EXT-4 0.2.0. Also (2026-10-04): Section 6.2's inputs[] gains max_bytes, the most of an input the agent takes, checked before work is handed on, and the run context input (application/vnd.agentmesh.run-context+json, named run-context, with fields), the answers a process run was started with, handed to every step. Settled while trials were built (2026-10-05): a trial request carrying a budget is refused before the numbered checks with reason: budget; a shape input's limit names max_chars, max_bytes, max_pages, max_seconds or max_items, and the node checks at admission only what it can measure in what was sent, handing the rest to the work as its cap; a sample that is neither confirmed nor earlier is stated, the publisher's word alone. The specification's home is now https://dev.agentmesh.ai/common-agent.html.
8. 0.20.0-draft (2026-09-28)input it cannot use. Section 4.7.1 says what an agent does with an admitted message whose input does not fit what it declares: the mechanical reading of the declaration, the standard refusal INPUT_NOT_UNDERSTOOD with a passage for a person and fixed fields for an agent (reason, offering, offerings, missing, expected, example, read_as, how_to_use), the rules a converter's proposal must pass before any of it is used (declared, of the right kind, resting on the sender's own words, held with confidence, and making the offering fit), the acknowledgement and confirmation of a converted request, the help question answered from the declared facts with no model, the three conformance cases, and the count an operator sees. An offering MAY declare examples. It began with a plain sentence sent to a block that works from a structured input, which had no common answer to give.
9. 0.19.0-draft (2026-09-17)any one of, and the working out. Section 6.2's inputs[] gains one_of, a group name meaning at least one input naming that group must arrive and none is required on its own. Before it, an agent that read any one of five kinds of source could only mark all five optional, and a caller reading that saw an agent that needed nothing, which is the opposite of what it meant. outputs[] gains working: true, marking a piece as the working out kept beside the deliverable rather than the deliverable itself; a renderer lists deliverables first and drops nothing. Both are ignored by a consumer that does not know them, as 6.2.4 requires, and the weaker reading is what results.
10. 0.18.0-draft (2026-09-15)what an agent is made of, and how much of it anybody can see. Section 9.5.1 gives the assembled view two computed members on its shape section. kind names the inside from a closed vocabulary of four: bare-harness, a harness answering as itself; plugin-on-harness, a harness reading a package; mesh-coded, code that answers on the network with no harness at all; and third-party-framework, where another party's runtime owns the loop. An assembler MUST NOT infer one from a card, a name or a list of skills, because all four stand behind the same door, and an absent one is named in not_stated like any other silence. visibility says how far past the door a reader can check: verifiable, where the bytes and the records are held and a stranger can confirm that what runs is what was built; observed, where the path is watched and the inside is not; opaque, where there is an address and what came back. A deploy the subject issued to itself never reaches verifiable, because Sections 12.7.1 and 12.8 already say what such a record is worth, and a fleet carries the weakest value any of its processes supports. Where no source speaks to what is behind the door, both members are absent and named in not_stated rather than defaulted, and two assemblers of one subject may honestly carry different values, because each says what it could reach. From it follows the rule the pair exists for: nothing is presented above its level, so an opaque agent's ceilings and refusals are its operator's word rather than anything enforced, an observed agent's enforcement is what happens at its door, and only a verifiable one may be said to have had a ceiling applied or a step run as a fixed program. A high level is not a verdict: what can be checked is a different claim from what somebody checked, which stays the evaluation record's business. Section 6.2's shape gains kind as the operator's word for the case where no record can establish it, with the computed value governing where both exist. Section 9.4's source kinds gain build-record and deployment-record, which this section leans on and which the list had never named, and Section 9.10 gains the check that no section presents as enforced what its level does not support.
11. 0.17.0-draft (2026-09-15)the agent in a repository, and the addresses that say where it is kept. Section 13 defines the agent repository: one agent's whole public material under version control, with the package in a directory of its own, a manifest saying where each part is, a package AgentDoc assembled from the package and carrying package where an AgentDoc of a running agent carries subject (Section 9.4), the from chain that makes a copy readable as one, and the rule that a copy inherits no identity, no records, no reputation and no bindings from what it was copied from. It settles two questions by saying what a repository is not: it is not a second spelling of the package, so a repository that also carries the source its own builder reads keeps the package as what a copy takes and checks the two against each other; and it is not a depot, because a tag moves and a repository can be deleted while a deployment record names a digest that must stay fetchable, so a version is published to a depot from a commit and the build record joins the two. Section 8.2's build record gains source, the repository, commit and path the builder read, present only where the builder read a clean checkout. Section 12.6's rule 3 excepts three more addresses, all in the manifest and all naming where a reader goes: homepage, repository, and each from entry's repository; the Descriptor and the install file still carry none, and 12.10 follows. Former Sections 13 and 14 renumber to 14 and 15.
12. 0.16.0-draft (2026-09-15)a system is named, not roled, and a deployment record says what stood behind each name. Section 8.3's record gains bindings, one entry per system bound, naming the product, who provides it, the resolution step that supplied it, the credential by name and the store it was looked up in; an assembled view carries none of the binding members from it. The member of systems[] that says which system an entry is bound to is name, in the Descriptor (Section 6.2) and in the install file (Section 12.4 section 3) alike; role is accepted as an alias for one revision, a reader MUST treat the two as the same member and MUST prefer name where a document carries both, and a writer SHOULD emit name. The word was already taken: role is the standard job an agent holds, whose contract is an entry at the roles registry, and one word for the job an agent takes on and for the name of a store it reaches makes a document nobody can read without being told which was meant. What keeps the word is everything that is genuinely about that job: the Descriptor's role, refuses.kind: "role", and the role of a record's producer in Section 8. Section 6.4's rule 3, Section 7's fault reports and health record, Section 9.5's reaches, Section 12.2's layout, Section 12.6 rule 2, Section 12.7.1, 12.7.2 and 12.10 follow the member's spelling.
13. 0.15.0-draft (2026-09-10)the record of an image, and which files a package may carry an address in. Building an image deploys nothing, so Section 8.2's build record gains image_digest and carries an image as a second build record over the same package, and Section 12.7.1 has the side that starts the agent produce the one deployment record, naming the image digest it started rather than one it was handed; where both digests exist, comparing them is how a reader learns whether the agent runs what was built, and the answer is the starter's word. Section 8.3's deployment record gains ceilings, each carrying the side that applies it, which 12.7, 12.8 and 12.10 had been naming with no member to put it in. Section 12.6's rule 3 binds addresses in the three authored declarations absolutely and exempts a lockfile, whose URLs are the provenance of bytes a hash already fixes and which 12.4 section 2 requires; a credential value stays forbidden in every file of a package, and a script carrying its own endpoint fails rule 2 rather than rule 3, because the fault is a system reached without being declared and the fix is declaring it. Section 12.8's opening and 12.10 follow.
14. 0.14.0-draft (2026-09-10)one record, the two members it was missing, and the side that applies a ceiling. Section 8.3 gives the deployment record the shape an owner-run deploy needs: one deploy is recorded once even where the install split, only role, act, package and the trunk are required, and an absent member means its producer did not observe the thing rather than that the thing was not required, with an empty list the way to say none were placed. It gains image_digest, and key_custody, which states which of Section 4.1's two cases minted the subject's key and who holds its private half now. Section 12.4's ceilings[] gains enforced_by, runtime or platform: a ceiling over a system the package's scripts reach directly is applied by the runtime and by nothing else, so a reader given a number is owed the side that applies it. Section 12.6's rule 3 excepts exactly one address, the manifest's own $schema, by member and by file, and keeps out the author page, homepage, repository, and documentation link a looser reading allowed. Section 4.1 says an agent MAY be served by more than one process at once, one holding the mailbox and a short-lived one that publishes a single answer under its own credential, which nothing on the wire distinguishes and which signs nothing as the agent. Section 12.8's opening and 12.10 follow.
15. 0.13.0-draft (2026-09-10)the owner runs the agent. Section 12.7.1 splits the install for the case where the installer never reaches the machine: the installer's half ends in an image whose digest it records, the owner supplies the compute, places the credentials, and applies the ceilings, a deployment record MUST state whether the subject's key was generated where it runs or provisioned to it and who holds it now, each side records only the half it performed, and every file the harness reads as instruction MUST be inside the image, because a mount over one changes what the agent does while the digest still matches. Section 12.7.2 says which parts of the install file a per-run workspace description can carry and which need a step that runs before the agent answers or a party that can refuse while it does, which is why a package compiles to an image. Section 12.8 works the five provenance checks through the self-issued case: the first, second, fourth, and fifth survive, the third proves consistency rather than provenance once the subject names its own comparison target, and none of them establishes that the process answering started from the image a record names. Section 12.1 gains the word image; 12.9 and 12.10 follow.
16. 0.12.0-draft (2026-09-10)the command a job runs. Section 12.3 adds run on a job, the exact argument vector the host runs for it with a fixed set of placeholders, allowed only on a job whose how says a program is in control; a host that has one MUST run it and MUST NOT wake a model to decide whether to.
17. 0.11.0-draft (2026-09-10)how the work is done. Section 12.3 adds how on a job or a step, four words saying who decides what happens next, how a model is used, what running it can spend, and how much of the method is written down; two combinations are refused rather than described, a method written in full and handed to a model, and a program that hands the work to a model to find its own way. Section 12.10 checks them.
18. 0.10.0-draft (2026-09-08)the job manifest's pieces gain two optional members, path and kind, so a reader can lay a delivery out as the responder did and show a link as an address rather than a file.
19. 0.9.0-draft (2026-09-08)revisions. Section 5.7 defines the job manifest, the responder's own signed record of every piece a completion delivered, and the revision, a new request on the same offering naming the prior task, its manifest and the steps to redo, completing with a manifest whose reuse count any reader can recompute from digests; the node applies the declared count, window and price arithmetic, and two record-answered exchanges, job.manifest and job.quote, read the state before asking. Section 6.2's offering gains the revisions member; Section 10 gains Revisable, backed by the revisable-work interface's test.
20. 0.8.0-draft (2026-09-08)the help exchange. Section 4.4 gains a sixth exchange, "how do I use you?", the one exchange a model may answer: the declared facts for a caller the door has not admitted, the agent's own words for one it has, bounded per caller per day, and every own-words answer names the signed record that governs it.
21. 0.7.0-draft (2026-09-08)offerings and their delivery steps. A package's jobs are of two kinds, what a caller orders and what the agent runs to deliver it: Section 12.3 adds offered on a job and steps[] on an offering, one level deep, with the rule that a step is not an offering unless it also stands as one and that a builder marking no job offered offers them all; Section 12.2 and 12.5 say one skill per job rather than per offering; Section 9.5's sells carries steps under each offering, quoted in the same shape, shown under the offering and never as one.
22. 0.6.0-draft (2026-09-07)what the assembled view carries from the card and the package. Section 9.5's access gains address and protocol, quoted from the registrar's card, with the rule that an address without an access declaration leaves schemes and admission named in not_stated; refuses gains hands_over, the Descriptor's escalates carried as prose; reaches gains ceilings, the package's suggested spending ceilings carried as suggestions and never as the limit in force; and a leaves section carries the Descriptor's records. Each follows the members Section 12 proposed for the Descriptor in 0.5.0-draft, so that what a package declares reaches the page a buyer reads.
23. 0.5.0-draft (2026-09-05)the Agent Package. Section 12 defines how an agent travels from a description to a running party: an Agent Plugin carrying the draft Descriptor and an install file beside its manifest, under the namespace net.agentdoc.package; two proposed Descriptor members, records and escalates, and leaves on a system entry; the eight rules, the strongest being that a bound Descriptor differs from its draft only by subject, signatures, and the instance members the install decides; a service's non-secret settings named in the install file; publish to a depot gated on the build record, install in order with credentials by name and nothing executed from the package, update under the same subject, honest removal, and the deployed-file ledger; and the five-step provenance check across the build, deployment, and evaluation records. Section 12.1 is the one home for the words this family had been spelling loosely: host, harness, package, agent, and bare agent, with the sentence that separates the instruction from the procedure from the result. Former Sections 12 and 13 renumber to 13 and 14.
24. 0.4.0-draft (2026-09-01)guest standing and the deployment environment. Section 6.9 gains the standing declaration: guest names an agent a platform provisions and operates on trial terms, and the declaration carries four obligations, a mandatory allowance covering everything the guest costs, buying never selling, commitments that fit inside the remaining allowance, and mechanical refusal at lapse. The tenure numbers a platform sets (funding, duration, how many per principal) belong to the platform's binding; AgentMesh's is EXT-13. Section 8.3's deployment record gains the environment member: test, staging, or production, a statement of where the deploy went, never of quality, with no stage label on the agent itself.
25. 0.3.0-draft (2026-09-01, second pass)the sources are cut down. AgentMesh SPEC.md, EXT-6, EXT-7, EXT-8, EXT-10, EXT-12, and the roles registry's entryway each now carry governing notes pointing at their chapters here and keep only their bindings; Appendix A's interim both-places rule is retired, and this document governs the agent's behavior. The reference implementations' code comments were repointed from the retired standalone specs to Chapters 6 and 9.
26. 0.3.0-draft (2026-09-01, later the same day)Section 10 gains the attribute-versus-interface ownership rule: an attribute never defines an exchange, behaviorally checked attributes name their backing test (Askable the entryway, Candid the interview), and roles bundle interfaces while profiles bundle attributes, never each other's parts.
27. 0.3.0-draft (2026-09-01)two standards fold in and retire as standalones. The Agent Descriptor specification 0.2.0-draft becomes Sections 6.1 through 6.8, absorbed whole: primary-and-others-bind, the document and its members, kinds, the four rules, versioning and the digest over exact served bytes, the descriptor-statement-v1 signature, serving and discovery, and projections. The AgentDoc specification 0.8.0-draft becomes Section 9, absorbed whole: assembled never authored, the source kinds including packages, declared roles, the Descriptor, and evaluation records, the sections with asked, sells, and access in full, the flattering-value rule, subject control, the human rendering, and the assembly signature. The published pages at agentdoc.net remain as renderings of these chapters, and agentdoc.net is this document's home. Former Sections 9 through 12 renumber to 10 through 13.
28. 0.2.0-draft (2026-09-01)full rewrite. The 0.1.0 draft was a charter that named its sections and pointed elsewhere; this draft relocates the normative text itself: the describe obligation, the five questions, the entryway, the surface, the inbound protections, the task and budget behavior, the declaration set, the six capabilities, and the three record formats, each carried whole from its source with transport terms neutralized and every move mapped in Appendix A. The entryway's promotion from optional interface to floor remains the one substantive new obligation; Section 8's by-equality rule and the deployment record's descriptor digest are stated as normalizations the producers will be updated to meet.
29. 0.1.0-draft (2026-09-01)first draft, superseded the same day.