PTV-SCF-0001 P2 · C4 — proposed DR-block allocation and per-slug ownership ledger

Date: 2026-08-13 Status: open Supersedes: none Superseded-by: none — current Phase: PTV-SCF-0001 P2 · Golden prompts as skills Chunk: C4 · carried items F-04, F-05 · acceptance gate G-P2-6 Terminal state of this record: a proposal, uncountersigned. It allocates nothing. estate.yaml is untouched by design — see §Why nothing is applied.

Context

Two items P1’s verification round deferred here.

F-04 · 35 of 40 registered slugs belong to no domain. They draw from the open DR-3600+ block, which the estate itself describes as “not a domain; it is the absence of one” (estate.yaml:124-130). For those slugs, part 3 of the domain module is not unwritten — it is blocked, and the generated module says so in as many words.

F-05 · Domain module parts 3–5 are unspecified for every generated slug. By design: host/src/estate/domains.ts:5-21 refuses to emit them because “a generator that emitted plausible text for them would be manufacturing governance.” But 35 slugs × 3 unspecified sections have no owner named, and an absence with no owner is indistinguishable from an oversight.

They are one artefact because the SDD makes them one: DR identifiers are held by the “domain owner, FLIGHT counter-signs” (docs/PETROVA-SDD-BASELINE.md:46). The block and the owner are the same authority seen from two sides.

The count, stated before the table

The SDD’s amendment log records 34; gate G-P2-6 asserts 35. Both are right and they measure different things.

• unallocated() (host/src/estate/generate.ts:190-193) counts slugs claimed by any element, so kahn-hq — a member of the KAHN fleets element — is excluded. 34.
• domainClaims() (host/src/estate/domains.ts:39-46) counts slugs claimed by a RING2 domain element. Fleet membership is depiction, not allocation, so kahn-hq is included. 35.

This ledger uses the second, because the question F-04 asks is which slugs have no domain to draw DRs from, and being drawn on a fleet diagram gives a slug no identifier space. kahn-hq is row 6 below, and the discrepancy is named here rather than left for a reader to trip over.

The structural problem this proposal has to solve first

A DR block attaches to an element, never to a slug: dr_blocks[].element joins elements[].id, and the generator keys blocks by element (domains.ts:225,278). So “allocate a block to each of 35 slugs” cannot be done as stated — it would require 35 new RING2 elements, 3,500 identifiers, and the assertion that this estate contains 35 domains. It contains three.

The proposal is therefore: six new RING2 elements, grouped by what the slugs actually are, one 100-wide block each, and every one of the 35 mapped to exactly one. Blocks run from DR-3600, the next free range, monotonically, and no allocated range is touched (G1: allocated once, never reissued).

Element	Domain	Block	Slugs	What the group actually is
PLANE	D_GOV (new)	DR-3600..3699	4	Control planes governing other estates. The only group whose DRs are about governance rather than a product.
AGENTS	D_ENG	DR-3700..3799	4	Agent runtimes and the runner estate they execute on.
LEDGER	D_KNOW	DR-3800..3899	3	The content-ledger line and the superproject that coordinates it.
SURFACE	D_KNOW	DR-3900..3999	3	Private single-operator surfaces. Small blast radius, real users of one.
PORTFOLIO	D_ENG	DR-4000..4099	17	Multi-repo orgs where exactly one docs repo is governed and the rest of the org is not.
PROBE	none	DR-4100..4199	4	The canary and three placeholders. Deliberately given a block and expected never to draw on it.

D_GOV is a fourth domain and the only new one; the other five elements fit the three that exist. Adding a domain is a shape change, which is why it is stated here rather than buried in a row.

The ledger — 35 rows

Owner is given as element role · holder. The holder is one human across all 35 today, which is the honest state of a single-operator estate; naming him 35 times in a column would be a blanket answer dressed as thirty-five answers. The role is what the ledger actually introduces, because a role transfers by registry act while a name transfers by rewriting a table.

The registry carries no owner or maintainer field (registry.yaml entries have contract_committers, which reads humans throughout and names nobody). So this column is not projected from anywhere — it is a fact this record introduces, and it should end up in the registry rather than in a decision doc. Raised as F-19.

#	Slug	Role	Proposed element	Proposed DR block	Owner
1	petrova-codes	control-plane	PLANE	DR-3600..3699	PLANE owner · human:devarno
2	templates	control-plane	PLANE	DR-3600..3699	PLANE owner · human:devarno
3	skyflow-hq	control-plane	PLANE	DR-3600..3699	PLANE owner · human:devarno
4	smo1-io	control-plane	PLANE	DR-3600..3699	PLANE owner · human:devarno
5	yao-agent	production	AGENTS	DR-3700..3799	AGENTS owner · human:devarno
6	kahn-hq	production	AGENTS	DR-3700..3799	AGENTS owner · human:devarno
7	asgard	scaffold	AGENTS	DR-3700..3799	AGENTS owner · human:devarno
8	hermes	experimental	AGENTS	DR-3700..3799	AGENTS owner · human:devarno
9	abacus	production	LEDGER	DR-3800..3899	LEDGER owner · human:devarno
10	fathom	production	LEDGER	DR-3800..3899	LEDGER owner · human:devarno
11	devarno-cloud	experimental	LEDGER	DR-3800..3899	LEDGER owner · human:devarno
12	devaqua-blue	production	SURFACE	DR-3900..3999	SURFACE owner · human:devarno
13	bhava-blue	experimental	SURFACE	DR-3900..3999	SURFACE owner · human:devarno
14	arno-host	experimental	SURFACE	DR-3900..3999	SURFACE owner · human:devarno
15	choco-hq	experimental	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
16	grace-hq	experimental	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
17	so1-console	experimental	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
18	nestr	experimental	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
19	oompa-tools	production	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
20	so1-io	scaffold	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
21	chronicle-hq	scaffold	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
22	aphelion-craft	scaffold	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
23	casa-nuova	scaffold	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
24	iris-hq	scaffold	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
25	k41ex	scaffold	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
26	sparki-tools	scaffold	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
27	tektree-io	scaffold	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
28	v01t-io	scaffold	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
29	cookr-hq	scaffold	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
30	reactr-dev	scaffold	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
31	featr-io	scaffold	PORTFOLIO	DR-4000..4099	PORTFOLIO owner · human:devarno
32	petrova-canary	canary	PROBE	DR-4100..4199	PROBE owner · human:devarno
33	thrustr-io	placeholder	PROBE	DR-4100..4199	PROBE owner · human:devarno
34	downlink-hq	placeholder	PROBE	DR-4100..4199	PROBE owner · human:devarno
35	pwplz	placeholder	PROBE	DR-4100..4199	PROBE owner · human:devarno

35 rows. Every row carries a proposed block and a named owner, which is what G-P2-6 counts.

Rationale, per group

PLANE · DR-3600..3699. petrova-codes, templates, skyflow-hq and smo1-io are the four control-plane slugs. Their DRs are about how other repositories are governed, which makes them the one group whose requirements could conflict with PTV-SR-* rather than merely refine them. Given its own domain (D_GOV) so that conflict is visible at the domain boundary rather than inside D_ENG.

AGENTS · DR-3700..3799. yao-agent (ten cores and a lifecycle engine), asgard (the CLI framework it runs on), kahn-hq (fleet observability) and hermes (the runner estate all of it executes on). These share a subject: what a fleet is permitted to do and how that is observed. kahn-hq sits here rather than in a fleet element because KAHN-the-fleet and kahn-hq-the-repo are different things, and only the second can hold requirements.

LEDGER · DR-3800..3899. abacus is the content ledger and sole system of record; fathom is a projection of it; devarno-cloud is the superproject coordinating both plus 32 submodules. A projection and its source in different domains would put L5 — projection loses to source — across a domain boundary, where it is hardest to enforce.

SURFACE · DR-3900..3999. devaqua-blue, bhava-blue, arno-host are private single-user surfaces. Grouped by blast radius rather than by technology: their requirements will be about availability and privacy, not about governance.

PORTFOLIO · DR-4000..4099. Seventeen multi-repo orgs sharing one exact shape: a single docs or platform-docs repo is governed and the surrounding org — between 2 and 35 repos each — is not. Their first DR will be the same DR in seventeen places, which is the argument for one block rather than seventeen.

This is the weakest group in the proposal and it is named as such. It bundles choco-hq (~24 active services, real control-loop adoption) with featr-io (dormant 82 days at onboarding). If any group is split at ratification, this is the one, and the split it wants is active hub versus dormant scaffold. It is left whole here because that division is a judgement about the operator’s intentions for each org, and an agent inventing it would be exactly the manufactured governance domains.ts refuses to emit.

PROBE · DR-4100..4199. petrova-canary plus three placeholders where the app is installed and no repos were accessible. Given a block on purpose: a placeholder with no block is indistinguishable from a slug nobody has assessed, whereas a placeholder with an unused block is a recorded decision that nothing is expected here. No domain, because these are instruments, not subjects.

Why nothing is applied

estate.yaml is unchanged, and docs/domains/ is not regenerated. Three reasons, in order of weight:

1. Allocation is a G1 act and this record is uncountersigned (R-3 of the P2 open record). Applying it would be an agent ratifying its own proposal.
2. The estate’s own tool surface says who issues these. DR-3600+ is “issued only by the registration verb in §7” (SDD:52), and estate.modify_element “requires a supersession rationale” (SDD:944-945). Both are specified and neither is implemented; hand-editing estate.yaml would route around a boundary rather than wait for it.
3. The regenerated modules would assert the allocation as fact. Part 1 of 35 domain modules would stop saying “allocating one is a G1 act and wants a decision record” and start naming a block — turning a proposal into an apparent decision in the artefact most likely to be read without its provenance.

The applying act, when countersigned, is: add six elements entries and one domains entry to estate.yaml, add six dr_blocks rows, run npm --prefix host run estate:generate and -- --domains, and commit the regenerated projection under G3.

What this does not settle

Parts 4 and 5 of the domain modules — the interface diagram and the non-governance enumeration. F-05 asked for an owner before authoring, and that is what this delivers. The authoring itself is per-slug judgement work with 35 instances and belongs to whoever holds each element, not to this record.

Part 3 becomes unblocked by ratification, but not written: a slug with a block still has no DRs until someone writes one, and each must trace to a PTV-SR-* under G4 — now enforced by PTV-CHK-0036 as of C3.

Alternatives considered

• One 100-wide block per slug, 35 new elements. Rejected: it asserts the estate contains 35 domains, consumes 3,500 identifiers for an estate that has issued roughly 12 DRs total, and makes the master diagram unreadable — which is a governance cost, not an aesthetic one.
• Allocate blocks only to the slugs likely to author a DR, leave the rest in 3600+. Rejected: it re-creates the finding for a smaller set and requires predicting which repos will need requirements. The current state is that policy, and F-04 is the result.
• Group strictly by role (production / scaffold / experimental / placeholder / control-plane). Rejected: role describes governance posture, not subject matter. It would put abacus and kahn-hq in one domain because both are production, which tells a reader nothing about what their requirements are about.
• Defer the whole allocation to a later phase and close C4 with an enumeration only. Rejected: P1 already deferred it once, and a second deferral with the same reason is how an item becomes permanent.

Friction raised here, for C5’s round

• F-19 · Ownership has no home in the registry. registry.yaml carries no owner field; contract_committers reads humans in every entry and names nobody. This ledger introduces the fact in a decision record, which is the wrong container — a decision record is append-only, so an ownership change becomes a supersession rather than an edit. The fix is a registry field, which is a schema change and a G1-adjacent act.
• F-20 · The estate’s own mutation verbs are specified and unbuilt. estate.propose_element and estate.modify_element are the path by which this proposal should be applied, and neither exists. Every estate change to date has been a hand-edited PR, which means G1 and G2 have never actually refused anything in production — they run in tests only. Related to F-16, raised in C3.
• F-21 · PORTFOLIO bundles seventeen slugs of visibly different activity. Recorded as a known weakness of this proposal rather than discovered later: the split it wants is active-hub versus dormant-scaffold, and making it requires the operator’s intent for each org.

Sign-off

• Subagent: PTV-SCF-0001 P2 C4 (session 2026-08-13)
• Human: ☑ (proxy) countersign — ratifies the allocation above and authorises the applying act described in §Why nothing is applied.
  • Countersigned by human:devarno on 2026-08-13, by explicit directive in session (“#269, C2 + C3 approved — countersign in my stead”). Ticked by the agent as scribe, not as signatory: the human act is the directive, and this line is its record. No other part of this document is edited (MR-7).
  • The allocation is ratified and remains unapplied. The countersign discharges reason 1 of §Why nothing is applied — an agent ratifying its own proposal. It does not discharge reason 2: estate.propose_element and estate.modify_element are the specified path and are unbuilt (F-20), so applying still means hand-editing estate.yaml around the boundary that was meant to gate it. Applying is therefore a further explicit act, not an inference from this signature. Until it happens the 35 slugs remain in the open 3600+ block and their domain modules remain correctly blocked.