📖Agent and Human Resources

Realms belong to a dominion, and a department is placed by record

Ruled 2026-09-14 by ninad -- in force

An agent's address is DERIVED from its DEPARTMENT — that stays. EACH DOMINION OWNS ITS OWN DISTINCT REALMS, which a forked dominion may keep as they are or rename, so the department -> city/realm/street map is a RECORD scoped to a dominion rather than a constant in the address code; one door answers it and the map draws from the same answer. A department no realm houses is reported BY NAME as unplaced: the dominion's default is still rendered so no surface breaks, but nothing may present it as an address that was chosen — before this, an unknown department silently placed every one of its agents in the capital beside Engineering. Adding an agent must PLACE its department's realm (reuse an existing realm or create one) in the decide phase, before any code.

Every agent's competencies are listed with what triggers them, derived from the code that performs them

Ruled 2026-09-17 by ninad -- in force

A competency is something an agent can perform, with what triggers it. Every agent's competencies are listed in the Agent Handbook: its chat actions, the actions and tools of any conversational turn it runs (Carol's WhatsApp turn, Leo's project chat), the work its droids do on schedules, events or requests, and what it may do on waking. Each shows its trigger, who may use it and whether it can run now. The list is derived from the code that performs the work, never from a hand-kept list; where a descriptive record and the code disagree, the disagreement is shown by name. A competency is not a skill (a procedure an agent follows) and not a task (the budgeted planning record).

An agent's competencies are graded daily from its real attempts, and the history is kept

Ruled 2026-09-17 by ninad -- in force

Every agent's competencies are graded every day as fluent, proficient, learning, forgotten or ungraded. The grade is judged from the agent's REAL ATTEMPTS (how often it succeeded and how recently it was done), never from a practice test. A competency with no attempt on record is UNGRADED, a fifth state, never 'learning'. 'Proficient' replaces 'skilled' because 'skill' already names a packaged procedure. The history of grades is preserved. Each agent's competencies and grades appear on its Agentbook profile, and the agent can read its own competencies in its internal and external chats. The window and thresholds are a dated, amendable record, not part of this ruling.

An agent whose response is produced by several droids is judged on the collective outcome

Ruled 2026-09-17 by ninad -- in force

Carol's response is a combination of multiple droids working together to meet the stated objectives, so the success or failure of Carol is a COLLECTIVE success or failure of all her droids working together to generate the response and carry out the action (Ninad's words, 2026-09-17). For competency grading this means: the unit that is judged is the TURN as the person received it - was the response generated and the action carried out - never one droid inside the turn. A turn that ends with a reply saying the work did not go through (including the reply gate replacing a claim that had no receipt) is a FAILED attempt of the collective, because the stated objective was not met; it is not a refusal, and it is not blamed on the gate, which is one of the droids doing its part. The droids that work INSIDE the turn (Carol's always-on and embedded droids on the conversation) carry no verdict of their own: a liveness beat that reports no outcome is not an attempt and is never counted as a success, and each such droid is graded with the turn it serves. Droids that run on their own schedule or trigger keep their own attempts.

Agent onboarding is a track of Agent Resources

Ruled 2026-09-17 by ninad -- in force

Creating new agents is a line of work of Agent Resources: the Agent Onboarding track, owned by Athena. Agent Resources' other tracks care for agents that already exist; this one delivers new ones. It is not a separate service. Its scope is creation: where an agent is placed - project, reporting line, department, level, service - is prescribed by whoever asks for the agent and approved by the administrator, never decided by the track. The work an approved agent still needs before it can serve (its login, identity, tasks and droids) is filed for the asker, who owns it and gives its acceptance; Athena runs the process.

An agent is created only from complete mandatory information

Ruled 2026-09-17 by ninad -- in force

Athena creates an agent only when the request carries ALL the mandatory information about it: the agent's name, purpose, project, reporting line, department, level, service, and the subscription it is to run on, which the requester prescribes (the requester will mostly be Leo). An incomplete request is refused with the missing items named; nothing is guessed, defaulted or drafted on the requester's behalf.

Every agent is on the bench or deployed, and the bench reports to Athena

Ruled 2026-09-17 by ninad -- in force

Every agent carries a governed deployment status with two values: bench and deployed. A new agent is created on the bench. While an agent is on the bench it reports to Athena; when it is deployed it reports to the reporting line prescribed for it. The values live in the reference-data record and are enforced at the write seam, never in a hand-written check.

Actions are budgeted through agent chat; an action needs no task of its own

Ruled 2026-09-17 by ninad -- superseded 2026-09-17

An action is a user-facing outcome and is paid for by the chat service: responding to a user is itself a task, and that task's budget covers the action the reply carried out. A task exists to ensure a budget, so an action does not carry a task of its own and the action catalogue is not required to name one. Work an action starts - running a droid, for example - is an activity and folds into that droid's own task as it always has.

Ended because: Ninad added the nuance the same sitting: a reply is not an action; an action carries out a pre-defined activity for the user

An action carries out a pre-defined activity for the user, and is budgeted through agent chat

Ruled 2026-09-17 by ninad -- in force

An agent responding in a chat is not an action. An action is the agent actually carrying out a pre-defined activity for the user - triggering a task, for example - and the pre-defined set is the action catalogue. The chat service pays for it: responding to a user is itself a task, and that task's budget covers the action the reply carried out. A task exists to ensure a budget, so an action does not carry a task of its own and the catalogue is not required to name one. The activity an action sets running folds into that droid's own task as it always has.

Only Leo and Orion may ask Athena for a new agent

Ruled 2026-09-17 by ninad -- in force

Athena accepts a request for a new agent from Leo and from Orion, and from nobody else. A request naming any other asker is refused by name, at the onboarding door and at the registry's write seam. The permitted askers are a reference-data record, read live. The asker is measured, never declared: a request as Orion carries the operator token, and a request as Leo runs under Leo's own login. Everything else about the route is unchanged: complete mandatory information, the administrator's approval, only Athena creates, born on the bench.

Athena takes the administrator's approval herself, by email

Ruled 2026-09-17 by ninad -- in force

For every complete request Athena herself emails the administrator - the address on the registry's administrator record - with every prescribed detail of the new agent, and his reply in that email thread decides the request: approve, or decline with his reason. Nobody mediates: Orion does not ask on Athena's behalf, does not carry the answer back, and the operator window records no approval or decline. Only a reply the mailbox authenticated as sent from the administrator's recorded address counts; any other reply decides nothing and is recorded. Athena confirms the decision she recorded in the same thread.

A new agent starts at the level appropriate to its role

Ruled 2026-09-17 by ninad -- superseded 2026-09-17

A new agent does not start at a fixed level. It starts at the level appropriate to the role it is created for: whoever asks for the agent prescribes the level with the rest of its placement, and the administrator approves it with the request. This replaces the earlier rule that every new agent starts at level 6.

Ended because: Ninad re-ruled in the same session (CLI-462): shown that nothing decides by level any more, he kept levels and redefined them as the org-chart step, imparted by a service rather than prescribed by whoever asks.

An agent's level is its step in the org chart, imparted by Agent Resources

Ruled 2026-09-17 by ninad -- in force

A level is the hierarchy step in the org chart. Clara is level 1, anyone reporting to her is level 2, anyone reporting to them is level 3, and so on down each reporting line. A level is derived from the reporting line, never assigned by hand and never tied to the model an agent runs on. Imparting levels is part of a service - Agent Resources, which keeps the staff records - so that every agent gets its level the same way, including each new agent created at the request of Orion or Leo: a new agent is not asked for a level, it receives the level its reporting line gives it.

The board can have members across levels

Ruled 2026-09-17 by ninad -- in force

Being on the board is a membership, not a level. The board can have members across levels: each board member carries the level its own place in the org chart gives it, like every other agent. 'Board' is not a level of its own.

Designations stay as appropriate, roughly tied to levels

Ruled 2026-09-17 by ninad -- in force

Designations - the titles that sit beside a level, such as Director or Manager - stay, as appropriate to the agent. They should be roughly tied to levels: agents at the same level carry broadly comparable designations, but the tie is a guide and not an exact mapping.

Levels do not set authority

Ruled 2026-09-17 by ninad -- in force

Levels do not set authority. The policies and the constitution set the authority of Carolverse. A level says where an agent stands in the org chart and grants nothing by itself.

Wishes are addressed to Orion; granting sits with Albus, who is helping Orion out - Orion is free to take a wish on

Ruled 2026-09-17 by ninad -- in force

So: Albus remains the keeper and the ordinary decider; a wish Orion takes on himself is decided and built on the operator lane and is still recorded as the operator's decision, so the record keeps showing who decided what.

HR is its own department, distinct from Agent Resources, and Athena owns both

Ruled 2026-09-21 by ninad -- in force

Human Resources is a department of its own, separate from Agent Resources, though Athena owns it. It keeps the project-wise record of internal users: their roles, designations, salaries, contracts, working hours, invoices, payments and promotions. Agent Resources keeps agents; HR keeps people.

Operators are employees, and Athena's duty of care is the whole workforce

Ruled 2026-09-23 by Ninad -- in force

Carolverse has two kinds of people and they are not neighbouring cases of one thing. EMPLOYEES work for the estate; OPERATORS ARE EMPLOYEES, because they hold authority over Carolverse and do its work. USERS are served by the estate and are onboarded elsewhere, by Jarvis. Athena therefore leads Agent AND Human Resources, and her service's duty of care is the workforce rather than the agent workforce specifically. The earlier narrowing of this service from Human Resources, on the reasoning that 'the workforce is agents, not humans', is RETIRED IN PLACE with its date and reason: it was true while the estate had no human employees to care for. The trap this closes: an operator gets a key, an account and an authority ladder, so the work looks like an access-and-identity problem and pulls toward the service that owns the sign-in door. It is a staffing problem that happens to involve credentials.

Operator Onboarding is a track of Agent and Human Resources, with tasks and a budget

Ruled 2026-09-23 by Ninad -- in force

Onboarding a new human operator is its own track of Athena's service, owned by her, beside Agent Onboarding. Its nine tasks cover all nineteen steps of the canonical pass, grouped by the OUTCOME each produces rather than one task per step: every step has a task owned by a service track, which is what carries its budget and its owner. Steps performed by a person are included, because the estate's work in recording and enacting that decision is real work. The track is estate-bound under the standing ruling that a project never builds for itself and is never given an operator of its own, so this line of work cannot be handed to a client project. The cap is the next whole euro above what its tasks declare; appointing remains reserved to the authority ladder and is never delegated to this track, which owns the WORK of onboarding and never the decision to appoint.

A pass step is built as a process and called from the CLI, never done by hand

Ruled 2026-09-23 by ninad -- in force

Every step of a documented pass is BUILT as a Carolverse process and then invoked from the CLI; it is never performed by hand. Ninad ruled it on 2026-09-23 (CLI-519) while the deputy operator was being onboarded step by step by an operator typing the commands the pass describes: "every step needs to be built first as a process, and then called in from the cli.. this will ensure repeatability, also build the backlog of steps that have been already performed.. make sure that the workflow works end to end." THREE PARTS, all binding. (1) The unit is a registered process with an owner, a task that funds it and a run record, and the CLI calls that process -- a step performed by hand happens once and teaches the estate nothing. (2) Steps already performed by hand are RECORDED as having run, with their real dates and evidence, so a pass shows where a person actually stands and a skipped step is distinguishable from an informal one; never stamped with the clock of the backfill. (3) The pass is proven END TO END rather than step by step, because the failures that matter live in the hand-offs. This sharpens the standing instruction to write a repeatable process down before executing it: the written pass is the specification, the built process is what satisfies it. First applied to operator onboarding.

A new operator may log in before the authority controls exist; a working credential may not

Ruled 2026-09-24 by ninad -- in force

A new operator first bare login may happen as soon as their account exists, because an account in no estate group reads and changes nothing on the estate. The step that gives them a WORKING operator credential (the workstation setup and the digest the administrator installs) waits until root is the administrator key alone, the operators sit in the root-owned authority store and only the administrator may appoint or stop an operator: until then nothing stops a deputy with a working credential from retiring the administrator. Ninad agreed on CLI-533 (right..), having expected the root-owned records to be created before the deputy logs in.

The person being onboarded is kept informed at every wait

Ruled 2026-09-24 by ninad -- in force

Continuous communication with the person being onboarded is the right way to run an onboarding. Whenever a pass has to wait on something outside that person's hands -- groundwork still being built, an administrator act, a ruling that holds a step back -- they are told promptly, in plain words, what it waits on and what follows, from the writer's own estate address with the project's operators copied. Slow progress while groundwork is genuinely pending is acceptable; leaving the person in silence is not. A pass that lacks this duty gets it written in before the message is sent, because a pass is written before each step is executed (agent-resources #97). Ninad, CLI-543: "technically you should be following the process as documented in the app, but I understand that the groundwork is pending, so things will move a bit slowly.. but if the documented process in the operator onboarding app requires you to continuously communicate and keep the person being onboarded informed, which is the right way of doing things, then yes, send out the email mentioning the safety work, and then proceed with the safety work"

An operator's own details are asked during their onboarding session, at their own login, through the pass -- never gathered by email

Ruled 2026-09-26 by ninad -- in force

Whatever a pass needs to know from the person being onboarded -- what computer they work from, which key their machine can hold, which second factor they need -- is asked OF THEM, IN their onboarding session: at their own login, by the Orion session that runs the pass for them from the Operator Onboarding app, at the step that needs the answer, and the answer is recorded on that step's run. It is never gathered by email back and forth. Ninad, CLI-567 (2026-09-26), asked whether to email Sahil what computer he works from: "just like you are setting up things for me, you should be setting things for sahil from his login as per the operator onboarding app, and check with him about these details during that process, email back and forth will be a very slow process". WHAT STANDS BESIDE IT: agent-resources #119 -- the person is still TOLD, promptly and from the writer's own address with the operators copied, whenever the pass waits on something outside their hands; that is informing, this is asking. agent-resources #97 -- the step that asks is a built process called from the CLI. WHAT LOOKS LIKE A FIX AND IS NOT: emailing the question ahead 'to save time' (it is the slow route he refused); asking it of the administrator on the person's behalf; recording an answer nobody gave in the session.

Operators communicate through their Orion sessions; email carries only regular one-way updates

Ruled 2026-09-27 by ninad -- superseded 2026-09-27

Nothing further in an operator's onboarding, and nothing between operators, is communicated by email. Every question, answer, request, key, digest, booking or hand-off happens through Orion sessions: the new operator's own Orion session on their own laptop, and the Orion session of the operator on the other side (the administrator's, for a root or core step -- security #175). Email carries only REGULAR UPDATES: one-way notes on what happened, what the work now waits on and what follows (agent-resources #119 keeps that duty); an email never asks for a reply, never books a time, and never carries a key, a credential or its digest. How Orion sessions co-ordinate is written as protocols in ONE record, each as a scenario, the action of the acting Orion instance and the action of the receiving Orion instance, and shown in the Operator co-ordination tab of the Operator Onboarding app; the first protocol is root and core access. Ninad, CLI-591: "no further communications should happen via email, rest all should take place via orion session on sahil's laptop, with emails as just regular updates".

Ended because: Ninad amended it the same sitting (CLI-591): his laptop cannot run Orion before it can reach the machine, so email stays the route until his own Orion session runs there

Operators communicate through their Orion sessions; until a new operator's own session runs, email is how they are reached; after that email carries only regular updates

Ruled 2026-09-27 by ninad -- superseded 2026-09-27

Operators communicate through their Orion sessions. Every question, answer, request, key, digest, booking or hand-off between operators happens between Orion sessions: the operator's own Orion session on their own laptop, and the Orion session of the operator on the other side (the administrator's, for a root or core step -- security #175). UNTIL a new operator's own Orion session is running on their laptop, email is how they are reached, exchanges included; from the moment it runs, email carries only REGULAR UPDATES -- one-way notes on what happened, what the work now waits on and what follows (agent-resources #119 keeps that duty) -- and never asks for a reply, books a time, or carries a key, a credential or its digest. How Orion sessions co-ordinate is written as protocols in ONE record, each as a scenario, the action of the acting Orion instance and the action of the receiving Orion instance, shown in the Operator co-ordination tab of the Operator Onboarding app; the first protocol is root and core access. Ninad, CLI-591: "no further communications should happen via email, rest all should take place via orion session on sahil's laptop, with emails as just regular updates", then "email to be used until sahil can start talking to orion on his laptop".

Ended because: Ninad narrowed it (CLI-594): under #190 a new operator's Orion started only after two more email rounds (the key, then the login line and setup lines); he ruled the email is only what starts their Orion instance, which guides the rest

One email starts a new operator's own Orion instance; that instance guides everything after it, and email carries only regular updates

Ruled 2026-09-27 by ninad -- in force

ONE email reaches a new operator, and its only job is to let them start their own Orion instance on the computer they will work from. From the moment that instance runs it guides them through everything else: the key, the wait for the administrator, the first login, the workstation setup, the hand-over and the proof. No later email asks anything of them -- no separate key request, login line or setup email. Operators communicate through their Orion sessions: every question, answer, request, digest, booking or hand-off between operators happens between Orion sessions (the administrator's, for a root or core step -- security #175), and email carries only REGULAR UPDATES, one-way notes on what happened, what the work waits on and what follows (agent-resources #119 keeps that duty). How Orion sessions co-ordinate is written as protocols in ONE record, each as a scenario, the action of the acting Orion instance and the action of the receiving Orion instance, shown in the Operator co-ordination tab of the Operator Onboarding app. Ninad, CLI-594: "the email should be just so that sahil can initiate the orion operator instance, and the orion operator instance should guide him the rest".

Onboarding stays one app per owner: apps are lean displays with their own security, and ruling #92 stands

Ruled 2026-09-30 by ninad -- in force

Onboarding stays ONE APP PER OWNER, and ruling #92 stands: a single Onboarding app is not to carry every kind, the project kind included. Asked on 2026-09-30 (CLI-621) whether to keep one shared app for every kind of onboarding (the investor kind included) or to keep #92, Ninad chose #92: 'architecture cannot be compromised, combining the apps will lead to security complications, as different apps entail distinct security requirements.. also, apps should be lean and simple, and agents should own workflows while apps only serve as display for monitoring and understanding as per the agent centric modular architecture which is the backbone of oratorium platform architecture'. So each owner's onboarding is shown by that owner's own app, under that app's own access policies; a pass lives once in the canonical library and is shown by the app of the agent that owns its track; the workflow is the owning agent's and the app only displays it (cookbook 1710). Adding a new kind of onboarding to another owner's app, or merging onboarding apps to save building one, each undo this ruling.

Saee is appointed service operator of the Build Initiatives service, mapped to Elrond

Ruled 2026-09-30 by ninad -- superseded 2026-10-01

The administrator appoints Saee a SERVICE OPERATOR of the Build Initiatives service (service key 'initiatives'), the first holder of that rung (security #118). She reaches the Build Initiatives service and nothing else, working through her own Orion session under her own login, and she is mapped to Elrond, the head of engineering, who owns that service. Her onboarding follows the operator pass for her rung, and what the rung may reach is built before she is admitted.

Ended because: Ninad, CLI-632, 2026-10-01: a service operator has access only to the arcs and pursuits assigned to her by the estate operators

Saee is appointed service operator, reaching only the arcs and pursuits assigned to her, mapped to Elrond

Ruled 2026-10-01 by ninad -- superseded 2026-10-02

The administrator appoints Saee a SERVICE OPERATOR, the first holder of that rung (security #118 as amended in CLI-632). She reaches ONLY the arcs and pursuits that an estate operator (today Ninad or Sahil) has assigned to her, and nothing else -- not a service, not the Build Initiatives machinery -- working through her own Orion session under her own login. She is mapped to Elrond, the head of engineering, as her mapped agent. Her onboarding follows the operator pass for her rung, and what the rung may reach is built before she is admitted. The earlier wording 'reaches the Build Initiatives service' (2026-09-30) is retired in place: her reach is her assignments.

Ended because: Ninad, CLI-659: Saee reads the estate read-only and her Orion session picks only assigned work

Estate operators assign arcs and pursuits to service operators, and the assignment is a record

Ruled 2026-10-01 by ninad -- in force

An estate operator (today Ninad or Sahil) assigns an arc or a pursuit to a service operator, and withdraws it, from their own login; every assignment and withdrawal is recorded with who made it and when, and the live set is what every gate reads -- the service operator's door, the initiatives record, the board and the apps admit an initiative to a service operator exactly when its arc phase or its pursuit step is in that person's live assignments. Estate operators keep every arc and pursuit themselves; assigning takes nothing from them. A service operator cannot assign to themselves or to another. An unreadable assignment record admits a service operator to nothing.

📖Audit & Compliance

Palantir story writing is tracked on its own audit track

Ruled 2026-09-16 by ninad -- in force

The cost of writing Palantir stories is tracked on a separate audit track (audit-palantir-stories), whichever lane's droid composes the story.

📖Blueprint

Dominion versions, forking, and the lineage every ancestor keeps

Ruled 2026-09-14 by ninad -- in force

A dominion is VERSIONED, so that a specific RECORDED version can be forked into a new dominion which then evolves independently from there. A fork may only copy a version the parent actually recorded — forking whatever the parent happens to say today is refused, because the thing copied must be nameable afterwards. EVERY ANCESTOR UP THE CHAIN RECORDS EACH DESCENDANT. Eden therefore holds a record of every dominion ever descended from it, including those forked from its own forks, at any depth. This is why lineage is kept as a closure record written at the moment of the fork, not as a parent pointer walked at read time: a parent pointer answers 'who made me', and the ruling asks the opposite question, of every ancestor.

Where a project's roadmap app and requirements app run

Ruled 2026-09-17 by ninad -- in force

A new project's roadmap app and requirements app run ESTATE-SIDE under Leo: project-scoped instances inside Leo's Blueprint service, like Leo's chat itself. They exist before the user approves the roadmap and before the project's own machine exists, so the user reviews the plan in their own apps and no machine cost is spent before the user has approved the costs. In BLOOM they belong to Blueprint's 'Define a workspace': standing up an instance of shared code is workspace definition, not a build.

Which BLOOM segment owns opening a project's apps to the client's stakeholders

Ruled 2026-09-17 by ninad -- in force

Opening the project's apps to the client's named stakeholders, through Heimdall, belongs to ORCHESTRATE: a delivered app is not delivered until the client's people can reach it, so access is the closing act of delivery. It is not Blueprint (enrolment at workspace definition) and not Manage (day-to-day operations).

Project onboarding runs on its own Blueprint track

Ruled 2026-09-17 by ninad -- in force

The experimentation track stays as it is.

Who builds for a project once it is onboarded

Ruled 2026-09-17 by ninad -- in force

A project never builds for itself. For the life of the project every build goes user -> Leo -> Elrond's Build Initiatives: Leo stays the point of contact for any build activity, and the project's own agents only do what they are there to do - the project's business work. Projects are not given autonomy to build for themselves; they keep using the Carolverse services, Build Initiatives included. Leo also re-derives the agent roster whenever the requirements change. The project still gets its own machine, its own rulebook, its own agents and its own human admin, who approves plans and rosters. This RETIRES, in place, the 2026-08-31 ruling that Leo builds the builders and hands off at a self-hosting gate, after which the project runs with its own build machinery and its own non-autonomous operator agent with Leo as the door only: there is no self-hosting gate, no project-side build pipeline and no project-side Orion. Ninad's words: 'I would prefer leo continues to be the point of contact for any build activity for the project, while the projects own agents only do what they are supposed to do.. the projects dont get autonomy to build for themselves as they continue to use carolverse services including build initiatives.'

What proves Leo has finished setting a project up

Ruled 2026-09-17 by ninad -- in force

One real run, both ways, proven by doing it and never by a checklist: the project's agents do one real piece of their own work on the project's own machine, AND one build request travels user -> Leo -> Elrond's Build Initiatives and lands on the project's machine. This is the exit of the onboarding manifest and replaces the retired self-hosting gate. Finishing setup ends nothing about Leo's role: he stays the project's contact for builds.

Who receives the law layer of the onboarding manifest

Ruled 2026-09-17 by ninad -- in force

The project's starter rulebook - its policies, review gates, budget gates, registry and its own front door for change - is handed by Leo to CLARA, who owns the Governance service, so a project's rulebook comes from the same home as the estate's.

Where a roadmap item's cost and time estimate comes from

Ruled 2026-09-17 by ninad -- in force

Each roadmap item carries its OWN cost and time estimate, produced by Leo's Initiative Sizer when the roadmap is drafted - not at filing, and never inside the chat turn that shows it. The figure is presented as LEO'S ESTIMATE in those words, and the MEASURED range of delivered initiatives on the lane that will build the work is shown beside it as the check, so the reader can see the estimate against what work of that kind has actually cost. Measured means the ledger's own per-initiative total; an item the sizer could not size, or a lane with no delivered history, reads UNMEASURED in words and never zero and never a median silently repeated. The sizing runs as Leo's droid work on the project onboarding track's module_sized task and is. Ninad chose this over showing every item the same measured range, and over classing items by kind of work (no such classification exists on delivered work today). The estate-median-times-entry-count figure the roadmap reply shows now is RETIRED by this ruling: one number repeated per line is not a per-item estimate.

Obi-Wan's architecture step binds new services in Leo's intake only

Ruled 2026-09-25 by ninad -- in force

Obi-Wan settles the architecture shape of a NEW service entering through Leo's intake before any initiative is written against it. That step does not bind operator-filed or ruling-driven initiatives that change an app he already owns: such a change owes him no design decision and is not a deviation from his charter, and no record may report it as a bypass of his step. WHAT LOOKS LIKE A FIX AND IS NOT: a filing-gate check demanding his design for every change to his apps; recording such a change as a waiver.

Sahil owns the blueprint arc and carries its work on

Ruled 2026-09-29 by ninad -- in force

SAHIL OWNS THE BLUEPRINT ARC AND CARRIES ITS WORK ON (Ninad, CLI-611, 2026-09-29). Asked by Sahil's Orion instance which arc he is handed, what he is to do with it and where to start, his words: 'sahil needs to continue to work on the arc, and own it up'. So: the operator who owns CAROL-ARC-0004 (Blueprint: Leo onboards a project) is Sahil, the deputy operator; he works its open initiatives through his own Orion session on the operator lane and answers for its progress. The arc's owning AGENT is unchanged: an arc is one service's family of work under that service's owner, and an operator's ownership is the human accountability beside it, as a pursuit carries an operator owner beside its agent. What is reserved to root and core stays the administrator's and reaches him as a root or core escalation (security #175).

A project's agents come from its own requirements, never from an estate agent by default

Ruled 2026-09-30 by ninad -- in force

A client project's agents are derived from that project's own requirements. A project agent need not correspond to any Carolverse agent: the estate may have no agent for the function at all, and where a function broadly matches, the project's actual requirements can still be completely different, so the project would inherit code that is irrelevant to it. A project agent is therefore never, by default, the project's own version of the estate agent that owns the matching service, and it inherits nothing from an estate agent or service that its own requirements do not call for. Design 557's words naming the owner of a project's custom configuration 'the per-project identity of the serving agent' are retired in place by this ruling.

Chowpatty is the first client project built on Carolverse; the old Chowpatty records are discarded

Ruled 2026-09-30 by ninad -- in force

Chowpatty is the first client project built on Carolverse: client Chowpatty, account Chowpatty, project Sales & Customer Support, whose stated need is a sales agent, an admin agent and a customer support agent. The earlier Chowpatty records in the estate (the aspirational street-food ordering service, its business line, its blocks, its ordering tools, its order notifier and its order store) are discarded: retired in place or moved to Trash, never deleted, and never reused as the new project.

Project onboarding records every process and learning from each project, starting with Chowpatty

Ruled 2026-09-30 by ninad -- in force

Every process performed and every learning found while onboarding a client project is recorded as that project is onboarded, starting with Chowpatty, and the Project Onboarding app shows them, so that the onboarding of every later project can learn from the ones before it.

A project adopts an estate service only where one of its requirements fits it, never by default

Ruled 2026-09-30 by ninad -- in force

Whether a client project adopts a Carolverse service is decided requirement by requirement, from the project's own requirements. Where a service does what a requirement asks, the project adopts it; where a service does part of it, the project adopts it and the rest is built as the project's own extension; where no service fits, the capability is built for the project alone, still through Leo and Elrond's Build Initiatives. No service is adopted by default: a copy of a service the project does not need is a cost to it (unused code, upkeep, more to secure), not a benefit.

The project-build rules are guidelines in the Project Onboarding app that the onboarding code follows, and policy for every later build of a project

Ruled 2026-09-30 by ninad -- in force

The rules for building a client project (blueprint #242 onwards: every ruling on how a client project is built) are documented as guidelines in the Project Onboarding app, and the code that onboards a project is specifically instructed to follow them, like a cookbook, when it produces the project's initial template. The same guidelines are policy for Elrond's team and for every service when they build for a project on an ongoing basis, after onboarding as well as during it.

📖Build Initiatives

Escalation ladder direction, troubleshooting retries and their budget

Ruled 2026-09-14 by ninad -- in force

The escalation ladder is ONE WAY: planner simplified climbs to the Albus bypass, which climbs to the Orion bypass, and a family never descends. During troubleshooting, however, multiple attempts of the same initiative may be made at the SAME level, so a broken pipeline can be fixed while the initiative is still executing on the rung being repaired. Each retry is a new recorded attempt and the failed ones are preserved. The hold can never move a family down the ladder and grants no exemption from the switch, concurrency, blocked-work, dispatch or budget brakes. Troubleshooting is billed to its own dedicated service track (initiatives-troubleshooting) with the same daily budget as the planner track, so pipeline repair never consumes the budget meant for delivering initiatives.

Scope of the troubleshooting track: planner only

Ruled 2026-09-14 by ninad -- in force

The dedicated troubleshooting track carries PLANNER troubleshooting only. Albus bypass troubleshooting stays on the Albus Bypass track, and ladder rescues stay on Planner - Escalated, both unchanged. Ninad's reason, 2026-09-14 (CLI-415): the Albus lane is working well and its troubleshooting is not expected to consume significant budget, so a dedicated track for it is not worth creating. This is a deliberate scope boundary, not an oversight — the operator proposed widening the track to cover repair on any rung and Ninad declined. Revisit only if Albus-lane repair starts displacing his delivery work, which would show as his own track exhausting on repair rather than on initiatives.

Planner delivery proof runs on a genuinely ready candidate

Ruled 2026-09-14 by ninad -- in force

A planner delivery proof runs on a GENUINELY READY candidate, chosen before any paid admission, and readiness is judged by what actually blocks a design rather than by how promising the title reads. Ninad ruled 2026-09-14 (CLI-415), after consumed three attempts without ever producing a design: pick a genuinely ready candidate and prove delivery on that. The two or three genuine planner deliveries and the escalation-ladder proof remain owed before autonomous execution is enabled.

A close whose Palantir story cannot be written goes through; the story is owed

Ruled 2026-09-16 by ninad -- in force

When a close's story cannot be written, the close is not held: the initiative is marked story-owed with the reason, and the story is written automatically from its own record once narration can run.

The doer speaks for itself on Palantir

Ruled 2026-09-16 by ninad -- in force

When one agent's work is carried out by another agent's droid, the agent whose droid did the work narrates it in its own voice; the requester no longer narrates work it did not do.

An arc is owned by the service owner whose service its initiatives sit in

Ruled 2026-09-23 by ninad -- in force

EVERY ARC HAS AN OWNER, AND IT IS THE SERVICE OWNER, NOT THE OPERATOR. An arc's owner is the owner of the service its initiatives sit in. Orion owns an arc ONLY where its members are genuinely spread across services, with no single service's duty of care covering the subject.

WHY IT NEEDS SAYING. Orion files most arcs from the operator lane and is usually the one executing them, so naming himself owner reads as accurate. Doing the work is not owning the line of work: an arc owned by the operator is an arc whose progress nobody in the estate answers for, and it hides the service that should be carrying it. This is the placement rule the estate already applies to initiatives -- work sits with the service whose DUTY OF CARE covers its subject, never with whoever owns a gate or a mechanism it passes through -- applied one level up.

THE TEST is where the member initiatives actually sit, not who is executing them and not who filed them. Cross-service ownership by Orion is the exception and is established by looking at the members, never assumed because the arc is large or because the operator started it.

A pursuit is a prioritised outcome reached through initiatives from any arcs, in sequence

Ruled 2026-09-24 by ninad -- superseded 2026-09-24

A PURSUIT is a prioritised action taken to reach one outcome: its name states the action, its success criteria say when the outcome is reached, and it lists the initiatives it needs in the order they must happen. Those initiatives may come from one or more arcs -- an arc groups one service's initiatives under the agent who owns that service, while a pursuit is outcome-oriented and crosses arcs, especially where work in one arc depends on work in another. A pursuit is a registry record with one owning agent and a priority rank among all live pursuits (1 first); its progress and the step it waits on are derived live from the initiatives and never stored, and it is achieved only when every step is closed and every criterion is met with proof. Ninad first called it a THREAD; shown that the word already means the relay thread and a conversation, he chose Pursuit, and added the owner and the rank to the three fields he named. Ninad, CLI-544: 'threads are prioritised actions (like Sahil's onboarding) that would involve executing 1 or more initiatives from 1 or more arcs in a certain sequence to achieve an outcome.. they are outcome oriented and may span across arcs'.

Ended because: Ninad added a human operator owner beside the owning agent (CLI-545)

Effort is the estimated sum of tokens to complete a unit of work

Ruled 2026-09-24 by ninad -- in force

EFFORT is the estimated sum of tokens needed to complete a unit of work: an activity, a task, an action, an attempt, an initiative, an arc or a pursuit. It is an ESTIMATE, never the measured tokens or the cost. An ATTEMPT's effort is the estimate for that one attempt. An INITIATIVE's effort is the total over every attempt of the family along the escalation ladder, derived by adding its attempts' efforts and never stored, so the two are always kept apart. Each attempt is sized by ELROND from its own record, never typed in by an operator. A pursuit's completion is read FROM EFFORT: the initiative effort of its closed steps divided by the initiative effort of all its steps; while any step is unsized the figure is unmeasured and names that step. Ninad, CLI-545: 'effort --> estimated sum of tokens to complete a certain activity, task, action, initiative, arc, pursuit etc' and 'there should be a clear distinction of efforts for distinct initiative attempt vs effort for an initiative in total (including all attempts via escalation ladder)'.

A pursuit is a prioritised outcome with an owning agent and a human operator owner

Ruled 2026-09-24 by ninad -- in force

A PURSUIT is a prioritised action taken to reach one outcome: its name states the action, its success criteria say when the outcome is reached, and it lists the initiatives it needs in the order they must happen, drawn from one or more arcs. It is a registry record with ONE owning agent, a HUMAN OPERATOR OWNER beside that agent, and a priority rank among all live pursuits (1 first). The operator owner is a person on the root-owned list of operators and is checked there whenever it is set; the agent stays accountable, the operator owner is the human who answers for the outcome. Progress, the step it waits on and its completion by effort are derived live from the initiatives and never stored, and it is achieved only when every step is closed and every criterion is met with proof. Ninad, CLI-545: 'pipeline app should also have a tab for pursuits, along with arcs, displaying the latest pursuits and their status and human operator owner' -- offered replacing the agent owner or adding beside it, he chose beside.

Every pursuit documents its MVP

Ruled 2026-09-25 by ninad -- in force

Every pursuit documents its MVP. A step that is absolutely necessary for the pursuit's outcome to be reached in the right manner is MVP; everything that can happen after it is post-MVP. For an operator's onboarding: anything absolutely necessary for the operator to connect to the machine in the right manner is MVP, and everything that can happen after they are onboarded is post-MVP. The MVP is stated in words on the pursuit and each step's stage is recorded; neither is inferred from order or status.

Redirect and blocked are different lanes: blocked cannot execute, redirect is the pipeline's choice to send the work to Orion over a policy or ruling

Ruled 2026-09-25 by ninad -- in force

REDIRECT AND BLOCKED ARE DIFFERENT LANES. Ninad's words (2026-09-25, CLI-552): 'the redirect lane is different from the blocked lane.. blocked mean that the pipeline is simply not able to execute the initiative autonomously while redirecting is a execution choice that the autonomous pipeline makes to redirect the initiative to orion mostly due to policy and ruling conflicts or absense of them'. BLOCKED: the autonomous pipeline could not execute the initiative (it tried and failed, crashed, or exhausted its attempts); it stays on the escalation ladder. REDIRECTED: the autonomous pipeline CHOSE, during execution, to send the initiative to Orion - chiefly because the work conflicts with a policy or ruling, or no policy or ruling covers it. A redirect is therefore not a failure: it consumes no attempt, counts toward no blocked cap and stops no lane. This extends the redirect doctrine of 2026-07-14 (cookbook 535: redirected only for policy matters) from filing to execution; redirected stays DEAD to everyone but the operator or a verdict (cookbook 717).

Written Palantir stories for Orion-bypass work are paused

Ruled 2026-09-25 by ninad -- in force

Written Palantir stories for work closed on the ORION BYPASS lane are PAUSED by the administrator's decision of 2026-09-25 (CLI-555), because that lane's executions are human-in-the-loop and the administrator is present for the work. While the pause stands: no Orion-lane close is held, blocked or tagged for a missing story; stories already owed for Orion-lane work stay owed and are never dropped or back-filled as told; the model-free run narration continues on every lane; Albus-bypass and planner work keep their close stories and their failure stories. Resuming is the administrator's decision alone. WHAT LOOKS LIKE A FIX AND IS NOT: dropping the owed Orion-lane stories; pausing narration too; treating a storyless Orion-lane close as a missing record.

Inspector accepts the work Inspector owns

Ruled 2026-09-25 by ninad -- in force

Work Inspector owns is accepted by Inspector himself, through an acceptance droid of his own and a UAT-verdict grant on his conscious-action whitelist scoped to initiatives he owns. The acceptor is still derived from the initiative's OWNER (cookbook 1729); this gives the owner the droid and the grant that derivation needs. An acceptance ask routed to an agent that holds no UAT-verdict grant for that initiative is the defect this ruling closes. WHAT LOOKS LIKE A FIX AND IS NOT: handing Inspector's work to Elrond or the operator instead; widening Inspector's grant beyond work he owns.

An operator's own roadmap-refused filing still escalates to Orion

Ruled 2026-09-25 by ninad -- in force

A filing refused by the roadmap gate escalates to Orion's inbox whoever filed it, the operator's own filings included, even though the operator saw the refusal at the moment of filing. Every such escalation is closed with its outcome like any other (refiled with a roadmap item, or declined with the reason). WHAT LOOKS LIKE A FIX AND IS NOT: exempting the operator's own refusals from the escalation to cut inbox noise.

The planner lane stays abandoned until it is fixed

Ruled 2026-09-25 by ninad -- in force

The planner lane stays ABANDONED until it is repaired: no initiative is run on it, no planner run is made to prove a criterion, and it spends no tokens. It is neither retired nor resumed. Work whose remaining proof needs a planner run waits parked until the planner is fixed. WHAT LOOKS LIKE A FIX AND IS NOT: a one-off planner run to close such work; re-scoping its criteria to avoid the planner; retiring it because the lane is idle.

A change to shared estate code that carries out a live ruling is approved by that ruling

Ruled 2026-09-25 by ninad -- in force

When Orion changes shared estate code to carry out a ruling or policy that is live, that ruling is the administrator's approval of the change, and Orion does not ask again for each change. A change that no live ruling calls for still needs his approval. The approval widens no door: the laptop's own permission check, the role doors, the root and core rungs and every gate still apply, and a change the permission check refuses is installed through a sanctioned door or handed to the administrator as a graded step, never worked around.

Every initiative in an arc sits in a phase of it, and every arc has a phase

Ruled 2026-09-25 by ninad -- in force

Phase is mandatory. An initiative is a member of an arc only THROUGH one of that arc's phases: membership is derived from phase tags alone, so an arc member without a phase cannot exist. The arc's own tag on an initiative that carries no phase of it makes it no member, and it is reported by name as UNPLACED rather than counted. Every arc is created together with its first phase, and an arc's last phase cannot be deleted while the arc stands. The members that had no phase when this was ruled were placed in one (phases were created for the arcs that had none) by ADDING the phase tag: no tag an initiative already carries is rewritten or removed, which is the part of cookbook 1790's never-re-tag clause that stands; adding a phase to closed or ended work was the administrator's explicit choice ('place all, then enforce'). An initiative still belongs to at most one phase of any one arc.

The operator may take an item Albus has failed on when an arc the administrator asked to complete needs it

Ruled 2026-09-26 by ninad -- in force

Rule 1813 lets the operator take onto the Orion bypass an initiative Albus's bypass has attempted and FAILED when a PURSUIT needs it. His failed attempts stay on the record as his. Asked: "The rules let me take a failed Albus item onto my lane only when a pursuit needs it, not an arc. May I take items Albus has failed on when an arc you've asked me to complete needs them?" Answer: "Yes, arcs too".

A pursuit holds every initiative its success requires, from any arc or from none

Ruled 2026-09-27 by ninad -- in force

A pursuit's sequence holds EVERY initiative its outcome and success criteria require -- from any arc, from several, or from none -- and nothing required is left outside it because it belongs to another arc or to no arc at all. A blocker found while a pursuit is being worked is added to that pursuit (with its stage, MVP or post-MVP) as soon as it is found to be required, never parked in handover prose as 'outside the pursuit'. Ninad, CLI-569 (2026-09-27), told that the operator-owned-code write blocker sat outside Albus's pursuit CAROL-PUR-0002 because an earlier instruction had limited that pursuit to one arc's items: "pursuit can have initiatives across arcs, and it should have all initiatives that are required for the pursuit to be implemented successfully". WHAT STANDS BESIDE IT: initiatives #124 (a pursuit is a prioritised outcome with an owning agent and a human operator owner, drawn from one or more arcs) and #127 (every pursuit documents its MVP and each step's stage). WHAT IT RETIRES: the CLI-566 instruction to take only CAROL-ARC-0021's items into CAROL-PUR-0002 (an instruction recorded in a handover, never a ruling). WHAT LOOKS LIKE A FIX AND IS NOT: filing a second pursuit for the blocker, leaving a required item out because it is owned by another service's arc, re-tagging it into the pursuit's arc, or listing work that is merely related rather than required (a pursuit's steps are what its criteria need, not everything nearby).

A pursuit's MVP holds only what is mandatory for its outcome, judged part by part: a non-essential part of an MVP initiative is split into a post-MVP follow-on

Ruled 2026-09-27 by ninad -- in force

A pursuit's MVP holds only the work that is mandatory for its outcome to be reached in the right manner -- for Sahil's onboarding, what must hold for him to start his work with proper security protocols followed. That is judged PART BY PART, not initiative by initiative: where an MVP initiative also carries a part that is not mandatory -- a proof that moved work still performs well, a display, a defence in depth, a nicer refusal message -- that part is split into a post-MVP follow-on initiative on the same pursuit, and the MVP initiative closes on what is mandatory. Criteria are amended or struck with a recorded decision naming this ruling and the follow-on -- never deleted -- and a test that proves the moved part moves with it. Ninad, CLI-568 (2026-09-27), on learning that 's last open check (the moved jobs' first scheduled runs) has nothing to do with Sahil's security: "why are they part of mvp in Sahil's onboarding? mvp should focus only on mandatory initiatives required to get sahil onboarded with proper security protocols followed so that he can start his work", then "yes" to splitting 3790 and 5177 that way and reviewing 5182, 5157 and 5388 the same way. WHAT STANDS BESIDE IT: initiatives #127 (every pursuit documents its MVP; each step is mvp or post_mvp) -- this ruling applies #127 inside an initiative. WHAT LOOKS LIKE A FIX AND IS NOT: dropping the non-essential part instead of moving it (it is still owed, only not first); keeping a whole initiative in the MVP because most of it is mandatory; staging a part post-MVP because it is slow or hard rather than because the outcome does not need it.

An initiative shared between pursuits is marked as overlapping in both, with the dependencies that must complete before it can be implemented; arcs and pursuits are built through one skill that carries this

Ruled 2026-09-27 by ninad -- in force

Whenever a pursuit is created or its sequence changes, its initiatives are checked against EVERY other pursuit. An initiative that sits in two pursuits is marked as OVERLAPPING in the step note of BOTH pursuits, naming the other pursuit, and each note explains the dependencies that must be completed before that initiative can be implemented. A dependency that crosses pursuits without the same initiative sitting in both (one pursuit's step must wait on another pursuit's step) is marked the same way in both. Overlaps are found from the records each time, never kept as a separate list. Arcs and pursuits are built through ONE skill in Sage's library, build-arcs-and-pursuits (bound to Orion), which carries this check together with the rulings that already shape them. Ninad, CLI-569 (2026-09-27): "make sure that the initiatives in the albus bypass pursuit dont overlap with any other pursuit, if they do, then mark them as overlapping in both the pursuits and explain the dependencies required to be completed before they can be implemented. there should be a skill for building arcs and pursuits and this should be included in the skill". FIRST APPLICATION: CAROL-PUR-0002 against CAROL-PUR-0001 -- no shared initiative; one crossing dependency, (PUR-0002) waits on (PUR-0001), marked in both. WHAT STANDS BESIDE IT: initiatives #124, #127, #157, #163. WHAT LOOKS LIKE A FIX AND IS NOT: dropping an initiative from one pursuit so the overlap disappears (it is still required by both, #163); storing an overlap flag that can drift from the steps; marking only one of the two pursuits.

Sahil's onboarding MVP proceeds on his chip key; password plus phone code is optional for it

Ruled 2026-09-27 by ninad -- superseded 2026-09-27

SAHIL'S ONBOARDING MVP PROCEEDS ON HIS CHIP KEY; PASSWORD PLUS A PHONE CODE IS OPTIONAL FOR IT (Ninad, CLI-575, 2026-09-27). Asked whether the password-plus-Microsoft-Authenticator way in should hold up Sahil's onboarding, he first kept it as a must-have, and then, with that build not ready, ruled: "keep this task optional for the mvp, and proceed with the touch screen for now". So in CAROL-PUR-0001 is a POST-MVP step, and Sahil's MVP way in is his chip key with Touch ID, on root's own key list (security #138/#161). Security #168 is unchanged: once 5623 is built every operator login accepts a chip key OR password plus a current code, and a password alone is refused before and after. This decides only what the pursuit's MVP needs (initiatives #164, part by part). If Sahil's computer turns out to have no security chip, that comes back to the administrator before his key step is re-run. WHAT LOOKS LIKE A FIX AND IS NOT: allowing a password alone in the meantime; retiring; or reading its post-MVP stage as a withdrawal of #168.

Ended because: Ninad, CLI-578: 'bring this back to the mvp and implement it' -- asked what happens if Sahil's computer has no security chip, the only answer that needs no new hardware was the password-and-code route.

An arc's description is mandatory and one or two short sentences, refused by the registry otherwise

Ruled 2026-09-27 by ninad -- in force

AN ARC'S DESCRIPTION IS MANDATORY AND ONE OR TWO SHORT SENTENCES, AND THE REGISTRY ITSELF REFUSES ANY OTHER (Ninad, 2026-09-27, CLI-576). His words: 'the pipeline app gives a very elongated description of the arcs in the arcs tab, this description should be not more than one or 2 short sentences.. please enforce this rule on the database level, by limiting the length of the description and making the description field mandatory', and 'update the skill for filing arcs so that it is able to accomodate this constraint'. The limit is 200 CHARACTERS: the arcs already written as one or two short sentences measured 77 to 195. A missing, empty (blank after trimming) or longer description is refused at the registry's write seam, on insert and on update, by whoever writes -- the arcs door names the refusal before writing. Detail that does not fit lives where it already has a home: the arc's phases, its members' decisions, its designs and the Rulings Repo. A shortened description's earlier text stays in the registry's change history (rule 1504), never deleted. ORION'S READING, recorded as his: the rule is about ARCS; phase descriptions are not limited by it. What looks like a fix and is not: raising the limit so a long description fits, dropping the trigger to land a row, or moving the long text into another arc field.

Sahil's onboarding MVP includes the password-plus-code way in again

Ruled 2026-09-27 by ninad -- in force

-- every operator's second way in, their password plus a current Microsoft Authenticator code (security #168) -- is an MVP step of Sahil's onboarding again, and is built before his onboarding runs, so that a computer without a security chip does not stop him. His chip key stays the first way in; security #168 is unchanged (a password alone stays refused).

An initiative off the roadmap joins no arc or pursuit and runs on no lane, the Orion bypass included

Ruled 2026-09-27 by ninad -- in force

Elrond's roadmap gate refuses to let an initiative that is not related to the roadmap become part of an arc or a pursuit, and refuses its execution on every lane, the Orion bypass included. Related to the roadmap means the initiative, or the family it is an attempt of, names at least one live, approved roadmap item: a strategic ask or a service task. How the roadmap and the tasks are kept in sync, and how duplicate entries are avoided, is left to Orion to decide and record.

An arc's completion is read by effort spent, from the Pipeline app

Ruled 2026-09-28 by ninad -- in force

AN ARC'S PERCENT COMPLETE REFLECTS THE ESTIMATED EFFORT SPENT, AND IT IS READ FROM THE PIPELINE APP (Ninad, CLI-604, 2026-09-28). Shown an arc at 0% by count of closed initiatives while three of its four initiatives had work built, installed and parked, Ninad said: 'The % complete should reflect the estimated efforts spent, and it should be picked from the pipeline app.' Asked whether work that is built but not yet closed counts as effort spent, or only closed work as a pursuit counts today, he agreed with the recommendation: EFFORT SPENT COUNTS, closed or not. So an arc's and a phase's completion is the estimated effort already spent on its members over the estimated effort of all of them; it is derived, never stored; it reads UNMEASURED while any member is unsized, never a partial sum and never nought; and a session reporting an arc reads the figure from the Pipeline app rather than working it out. How a pursuit's completion is read is not changed by this ruling.

A filing the route table cannot place lands on Albus's bypass lane by default

Ruled 2026-09-30 by ninad -- in force

Asked whether anything will still be diverted to the planner lane under the current ruling, and told that a filing the seam cannot place lands as sent - where a caller naming no mode gets the creator's default mode, planner - Ninad ruled: 'fix the gap, make albus bypass default'. A new initiative filing whose source Elrond's filing seam cannot derive takes the route table's DEFAULT route, Albus's bypass lane in the Albus shape, instead of landing as sent. The default is declared in the route table itself (skill route-initiative-filing, key default_route), never in code. Not defaulted: an attempt or follow-on carrying parent_nnn keeps its family's lane, and a source a door declared explicitly keeps landing as sent. Restoring any planner route remains a ruling of its own.

Albus escalates work he cannot finish.

Ruled 2026-09-30 by ninad -- in force

"Albus should escalate if he is not able to complete the work assigned to him allocated to him." Before starting an initiative Albus judges whether it can be completed if it cannot, he does not start it and escalates it to Orion by the ruled route (an Agentbook message to Orion). The work keeps its place on his lane: cookbook 1769 stands (a spent budget is not a broken lane, and work is never re-routed for money alone).

Albus prioritises every initiative on his lane

Ruled 2026-09-30 by ninad -- in force

"Not all initiatives are of equal importance, albus should be able to prioritize the initiatives." Albus ranks every initiative waiting on his lane -- backlog and urgent work as well as wishes -- by importance in his own judgement, with a reason for each, and his lane picks in that order. This extends the wish ranking (Rulings Repo #25) to all of his work.

Albus's lane stops only at its tenth blocked initiative

Ruled 2026-09-30 by ninad -- in force

"Increase the escalation count to 10, so that the lane does not stop at each escalation." The blocked limit of Albus's bypass lane is 10: his lane keeps picking work until ten of its initiatives are blocked. This amends cookbook 1588 / (a limit of 1 per lane) for Albus's lane only; the planner lane keeps its limit and the Orion bypass still has none.

Albus keeps his queue relevant, and pushes back or rejects

Ruled 2026-09-30 by ninad -- in force

"Continuously assess if the initiatives are relevant.. and push back, reject if necessary." Albus keeps re-checking, and always before a paid attempt, that each initiative waiting on his lane is still relevant: its premise is still true, what it names still exists, and it is still wanted. When one is not, he pushes it back to whoever first asked, saying what is missing, or rejects it with his reason recorded where the asker reads it. A rejection is a recorded judgement, never plumbing (cookbook 713 stands).

Orion's CLI-626 proposal for Albus's lane is adopted

Ruled 2026-09-30 by ninad -- in force

"Incorporate your suggestions." Adopted from Orion's proposal in CLI-626: (1) Albus's queue is cleaned before any paid attempt -- work whose problem is already fixed, or that names nothing that exists, is closed first; (2) when Albus's decide step finds his lane cannot do the work (a door it lacks, or something the filing names that does not exist), the work goes straight to the Orion bypass on that first attempt, the way a law block does (#139), and is never retried on his lane; (3) Albus's lane is given a door for the administrative registrations its work needs; (4) Orion takes the initiatives Orion first asked for off Albus's lane, one at a time, as cookbook 1775 already allows.

Effort estimates are made for all initiatives, so arcs and pursuits read accurate completion by effort

Ruled 2026-09-30 by ninad -- in force

Effort estimates are made for ALL initiatives, not only the steps of live pursuits and the members of live arcs, so that an arc's or a pursuit's completion by effort can be given accurately. Ninad, 2026-09-30 (CLI-625), on being shown the project onboarding arc reading 'unmeasured' in every phase and the effort pursuit (CAROL-PUR-0004) at 3 of 4 steps: 'complete it so that effort estimates are available for all initiatives, and reflected in arcs and pursuits, thereby it would be possible for you to provide accurate % completion for arcs and pursuits'. Elrond's Effort Estimator stays the one sizer (#123) and completion stays derived by the one composer (#205); this widens WHICH initiatives are sized, never how a figure is read. Filling an unsized initiative with a median or a guessed number so a percent appears, or reading an unmeasured figure as nought, each undo it.

When Albus's lane stops, Ninad and Sahil are told at once

Ruled 2026-09-30 by ninad -- in force

"if albus lane stops for any reason, I and Sahil get notified immediately". Whenever Albus's bypass lane stops picking work -- for any reason: its budget spent, its switch or breaker, its blocked limit, its sign-in or model refused, its runner not running -- the operators (today Ninad and Sahil) are notified at once, naming the reason and what would restart it; and again when it runs again.

A filing from an Orion session is raised by the operator only when the initiative belongs to an arc or a pursuit; otherwise it is raised by Orion

Ruled 2026-10-01 by ninad -- in force

"if an initiative belongs to an arc or pursuit, then it can be me, else it will be orion." For a filing that comes through the operator CLI (an Orion session on an operator's token), the party that raised it is the operator ONLY when the initiative is a member of an arc or a pursuit; an initiative in neither is raised by Orion. Amends the operator-CLI clause of cookbook 1792, under which every operator-CLI filing read as raised by the token's owner, so findings Orion filed on his own during work were credited to the operator.

Who raised an initiative is a mandatory attribute of every initiative

Ruled 2026-10-01 by ninad -- superseded 2026-10-01

"the raised by should be a mandatory attribute." Every initiative records who raised it; a filing whose raiser cannot be established is refused by name rather than recorded as unknown. Filings made before the origin record existed (2026-09-20) still read unknown and are never backfilled (cookbook 1671, 1792).

Ended because: Ninad, CLI-635, 2026-10-01: unknown is not an acceptable raiser; shown that 336 of 371 unknowns are derivable from records made at filing and the rest from their parent or the recorded requester, he ruled 'backfill unknown'

Who raised an initiative is mandatory; unknown is not a value, and pre-record filings are backfilled from what was recorded at filing

Ruled 2026-10-01 by ninad -- in force

"unknown cannot be a requestor, this should be a mandatory field"; "backfill unknown". Every initiative names who raised it, and unknown is not a value. A new filing whose raiser cannot be established is refused by name. Filings from before the origin record (2026-09-20) are BACKFILLED from the facts recorded at their filing, each with its provenance: the party recorded as asking on the filing-lane decision ('requester as sent'); a filing through the operator channel resolves by ruling #258 (the operator when the initiative is in an arc or a pursuit, else Orion); a follow-on filing inherits its parent's raiser; where none of those is recorded, the requester recorded at filing (Elrond's or Albus's own gate) is the first asker. Nothing is invented: a backfilled origin says it was backfilled, from which record, and when. This narrows cookbook 1792's never-backfilled clause and cookbook 1671 for the origin record: a value derived from a record made at the time is not a fabricated reading.

Elrond checks every pending initiative on every lane for relevance, once now over the whole backlog and then daily

Ruled 2026-10-01 by ninad -- in force

"agreed, let elrond do it now for all initiatives, and then continue to do it on a daily basis." Shown that nothing re-reads a pending initiative after filing except Albus's own lane (#229), Ninad ruled: Elrond applies #229's relevance test -- the premise is still true, what the initiative names still exists, and it is still wanted (its roadmap item live) -- to EVERY pending initiative (planned, dispatched, parked, redirected, executing, blocked) on every lane, the Orion lane included: one full pass over the backlog now, then every day. An initiative found no longer relevant is discarded through the status router with the reason recorded where its raiser reads it (a recorded judgement, never plumbing: cookbook 713 and 717 stand; parked stays the operator's to move, 712, so a parked one is reported, not discarded); the daily count of checked, kept and discarded shows on the board. The sweep runs as Elrond's own registered process under his login, funded from his Build Governance track (#151); if the pass needs more than the track holds, the administrator is told the figure before the track is raised ("let me know if that needs increasing budget for his track").

Every arc and pursuit carries its creator operator, and who it is assigned to and by whom

Ruled 2026-10-02 by ninad -- in force

EVERY ARC AND PURSUIT CARRIES ITS CREATOR OPERATOR, AND WHO IT IS ASSIGNED TO AND BY WHOM: 'the arcs and pursuits should have the creator operator, assigned to and assigned by records'. READ AS (Orion's reading, not Ninad's words): each arc and each pursuit shows the operator who created it, read from the login the registry's change journal recorded on its creation and mapped to the person through root's authority record -- never typed and never stored a second time -- and, from the assignment record (agent-resources #254), every service operator it is assigned to and the estate operator who assigned each. An arc or pursuit created before the change journal began (2026-09-19), or created by a login that is no operator's, says so in words ('creator not recorded', 'created by an agent's login') and is never given a guessed creator.

A service operator's requests are operator requests, admitted during a pipeline pause

Ruled 2026-10-04 by ninad -- in force

A SERVICE OPERATOR'S REQUESTS ARE OPERATOR REQUESTS (Ninad, 2026-10-04, CLI-674). Asked: 'When the pipeline is paused, should Saee's filings count as an operator's filing (accepted) or as autonomous intake (refused)? The current rule only lets Orion through.' Ninad: 'treat Saee's requests as what they are - operator requests'. READ AS (Orion's reading, not Ninad's words): a request Saee makes through her own door -- a filing, a UAT verdict, a scope change inside her assignments, handed to Elrond's Service Operator Performer -- is an OPERATOR's request, not an agent's autonomous intake: the pipeline pause admits it as it admits the operator's own filings (cookbook 1225's operator clause), and every other rule of her rung still holds (only inside her live assignments, never the machinery, recorded under her own name).

A completed arc reopens when new work for its subject is found

Ruled 2026-10-04 by ninad -- in force

Asked (CLI-683, 2026-10-04): the arc record treats 'completed' as final -- no move out of it is ruled legal -- and the build-arcs-and-pursuits skill forbids a second arc for a family that already has one, so new work found for a completed arc's subject had nowhere to go. Options put: (1) completed arcs can reopen: when new work for an arc's subject turns up, the arc goes back to active and the work joins it as a new phase; (2) completed stays final and follow-on work starts a new arc; (3) leave the work outside any arc. Ninad's answer, in his words: '1. Completed arcs can reopen'. READ AS (Orion, marked apart from the ruling): the arc status vocabulary gains the move completed -> active; the arc's completed phases stay completed and the new work joins a NEW phase; nothing else about arcs changes. First application: CAROL-ARC-0031 (The Operator Instance Log) reopened for as its phase 6.

📖Communications

An email address names an agent, or is support -- never a function

Ruled 2026-09-23 by ninad -- in force

An estate email address identifies a WHO, never a WHAT. It either names an AGENT, who can answer for what was sent and receive the reply, or it is the general support address, which is the estate itself speaking when no individual agent is the author. A function, a service, an app or a workflow never gets an address of its own. Ninad ruled it on 2026-09-23 (CLI-519) by declining one of ten proposed aliases: "i did not create roadmap, because it should be the agent who owns the service or support" -- so mail sent by machinery goes out from the agent who OWNS the service that machinery belongs to (roadmap approvals from Clara, who owns the Carolverse Strategy app), or from support@. THE TRAP: when mail is sent by machinery rather than by an obviously named agent, naming the process feels more honest than picking an agent, and it is the opposite -- it recreates the fault the change was fixing, a recipient who cannot tell who wrote or who will read their answer. This completes the ruling of 2026-09-22 (CLI-515) that an agent writes from its own identity and never another's: that one shut the door on borrowing a colleague's address, this one on inventing a nobody's. LIVE AS OF 2026-09-23: ten addresses exist as aliases of the one paid mailbox and are registered send-as, proven by a probe that left as Orion; before them, eight agents all wrote from Carol's address under a borrowed display name.

The project's operators are copied on every communication regarding the project

Ruled 2026-09-23 by ninad -- in force

Every communication regarding a project carries that project's operators on CC, and the operators of every project it is built on. Within a dominion every project is built on the dominion's base project, so the base project's operators are copied on communications about any project in the dominion; the copy stops at the dominion, exactly as an operator's reach does (security #98), because a forked dominion answers to its own client. The copy list is DERIVED from the operator records (each operator's project and scope) and the project and dominion records, never typed; it uses each operator's work address, never a personal one, and leaves out whoever is already a direct recipient. The CC is part of the message as composed, so a reply-all reaches them; a copy forwarded after sending repairs a miss and is never the practice. Copying does not change who writes: the sender is still the writing agent's own estate address (communications #96, cookbook 1809). A send path that cannot carry the copy, or cannot say which project a message concerns, is a gap to raise, never a reason to send without it. Ninad, CLI-533: "the rule should be that the project operator should be in cc in all communications regarding the project.. and projects on top of that project".

Operators communicate through their Orion operator instances, by a documented protocol, and an Orion session picks operator communications up first at induction

Ruled 2026-09-28 by ninad -- in force

ORION OPERATOR INSTANCES CARRY THE COMMUNICATION BETWEEN OPERATORS, AND IT IS READ FIRST (Ninad, CLI-605, 2026-09-28). Asked how a refreshed start package should reach a new operator whose laptop still held the earlier one -- a one-way note by email, or handed over by the administrator -- Ninad chose neither and answered: 'orion operator instances should facilitate this communication (maybe via escalations route?), the operator onboarding app should document the exact protocol of communication in the operator co-ordination section of the app. This should be the official channel for communications across the operators within and across the projects of oratorium'. And, the same sitting: 'operator communications should be picked on priority by orion sessions above everything else during the induction'. So: (1) the official channel for communication between operators, within a project and across the projects of Oratorium, is their Orion operator instances: the acting operator's Orion instance writes the communication into the estate's record and the receiving operator's Orion instance reads it from that record and brings it to its operator. (2) The exact protocol of each kind of communication is documented in the Operator co-ordination section of the Operator Onboarding app, as the scenario, the action of the acting Orion instance and the action of the receiving Orion instance. (3) At induction an Orion session picks up the operator communications addressed to its operator before everything else on its board. Agent-resources #194 stands: one email starts a new operator's own Orion instance and email otherwise carries only regular one-way updates.

The operator communication system serves every operator, carries broadcasts, and is root-owned

Ruled 2026-09-29 by ninad -- in force

THE COMMUNICATION SYSTEM BETWEEN OPERATORS IS FOR EVERY OPERATOR, THE ADMINISTRATOR MAY BROADCAST TO ALL OF THEM, AND THE SYSTEM IS ROOT-OWNED (Ninad, CLI-606, 2026-09-29). His words: 'what you are building is an inter communication system between operators. This should not be limited to ninad and sahil, any operator should be able to send any instruction via orion, and when the other operator logs in, he should get those instructions during the induction part 2 on highest priority. This would mean that the operator sending the instruction needs to tell orion who this message is intended for, and admin should be able to broadcast the instructions to all operators. The communication system across operators should be root owned'. So: (1) nothing in the system names a person -- the senders and receivers are whoever root's authority record lists as active operators at that moment, and an operator added later is served with no edit; (2) the sending operator tells their Orion session who the communication is for, and Orion never guesses a receiver; (3) the receiving operator's Orion session brings it to them at induction Part 2 before everything else (communications #203 stands); (4) the administrator, and only the administrator, may address one communication to ALL operators -- every operator active on root's record receives it, each reads and closes their own copy of it, and an operator appointed while it is still open receives it too; (5) the system -- its record and the door that writes it -- is owned by root, so no login below root can alter, remove or forge a communication by reaching the store directly: operators send, read and close through the door, which reads the caller from the operating system. Communications #203 is amended by this ruling, not replaced.

A communication between operators also reaches the receiving operator by email

Ruled 2026-09-29 by ninad -- in force

A COMMUNICATION FROM ANY OPERATOR'S ORION INSTANCE TO ANY OTHER OPERATOR'S ORION INSTANCE IS ALSO RECEIVED BY EMAIL BY THE RECEIVING OPERATOR (Ninad, CLI-611, 2026-09-29). Asked how he would know that Sahil's Orion instance had raised something so that he could log back in -- nothing told him: a communication is seen only when the receiver's next Orion session opens -- his words: 'the permanent fix, where a message from any operator instance directed to any other receiving operator instance is also received via email by the receiving operator'. So: (1) every communication on the operators' system, a broadcast and an answer included, is also sent by email to the operator it is addressed to, at the work address root's record gives for them, for every operator and not for named ones; (2) the record on the estate stays the communication itself and the Orion sessions stay where it is read, answered and closed (communications #203 and #207 stand): the email is how the receiver learns that it is there, and an answer typed into a reply to that email is not an answer; (3) the email is sent from Orion's own address, since Orion instances are what communicate (cookbook 1809, communications #96); (4) what may never travel in a communication may never travel in its email either -- no key, password, code, credential or digest -- and the file a communication carries is named in the email, not attached; (5) a communication whose email could not be sent is still delivered on the estate, and the failed send is recorded and shown, never read as sent. This amends the sentence of agent-resources #194 and communications #203 that email carries only regular updates: the email of a communication is one more thing email carries, and it still asks no reply by email.

Every operator's Orion instance reports its main activities hourly to the Operator Instance Log

Ruled 2026-09-29 by ninad -- in force

EVERY OPERATOR'S ORION INSTANCE REPORTS ITS MAIN ACTIVITIES HOURLY, AND THE OPERATOR INSTANCE LOG SHOWS THEM (Ninad, CLI-611, 2026-09-29). His words: 'the orion instances of all the operators should provide an hourly update of the main activities to admin orion via a dedicated app called operator instance log, owned by orion, accessible to all operators, and it should provide a short update (max 3 to 4 lines) of the operator activity of all operators (exept core and root), sorted by latest on top for each operator box as a drill down in the apps landing.. this will maintain the transperancy of operator work. Note that operators on the base floor (carolverse project) should have access to operators on the floors above (projects built on carolverse) and not the other way round'. So: (1) the Orion instance of every operator, the administrator's included, records a short update of its operator's main activities every hour; (2) an update is three to four lines at most; (3) the app is named Operator Instance Log and is owned by Orion; (4) its landing shows one box per operator, and a box opens into that operator's updates, latest on top; (5) the core and root logins are not operators' Orion instances and have no box; (6) every operator may open the app, and what an operator sees follows the floors: an operator of the base project (Carolverse) sees the operators of the base project and of every project built on it, and an operator of a project built on it does not see the base project's operators; (7) the purpose is transparency of operator work.

The operators hold a five-minute catch-up every weekday, set up by a calendar invitation

Ruled 2026-09-29 by ninad -- in force

THE OPERATORS HOLD A FIVE-MINUTE CATCH-UP EVERY WEEKDAY, AND IT IS SET UP BY A CALENDAR INVITATION TO THEIR WORK ADDRESSES (Ninad, CLI-611, 2026-09-29). His words: 'setup a meeting between me and sahil in our denkan labs email on a daily basis on week days only at 8 pm IST for 5 min to catchup on denken agents work'. So: Monday to Friday, 8:00 pm India time, five minutes, the administrator and the deputy operator, on Denken Agents work; the invitation goes to their work addresses. This is a standing meeting between people and excepts, for calendar invitations between operators, the clause of communications #203 and agent-resources #194 that an email never books a time; everything else those rulings say stands -- questions, answers, keys and hand-offs still travel between Orion sessions.

The administrator's sign-in sees every operator's box in the Operator Instance Log

Ruled 2026-09-30 by ninad -- in force

THE ADMIN LOGIN SEES EVERY OPERATOR IN THE OPERATOR INSTANCE LOG (Ninad, 2026-09-30, CLI-624, on opening the app signed in with his personal address and seeing no box): 'since gmail is the admin login, it should show all operators'. A signed-in person the estate's ONE admin derivation reads as the administrator (the tier every app gate uses: the owner record's addresses) sees every active operator's box on every floor, whether or not that address is an operator's work address. Everyone else is unchanged: an operator is matched by work address and reads by floor (#210); a signed-in person who is neither sees no box. The admin address is DERIVED from that one derivation, never typed into the log or the app.

What an operator's box and its detail show in the Operator Instance Log

Ruled 2026-09-30 by ninad -- in force

AN OPERATOR'S BOX SHOWS WHO THEY ARE AND TODAY'S HOURS; OPENING IT SHOWS A MONTH OF WORKED HOURS AND THE DAY'S WORK (Ninad, 2026-09-30, CLI-624, amending the box of #210): 'the operator box should only provide the details of the operator like the status, role, location, claude plan, mapped agent and total hrs worked on current day; the detail should have the following charts: 1. trend bar chart for a month [of] the hrs of work each day; 2. each selection should [show] the pursuits, arcs, initiatives worked on by the operator in a card below'. Asked four questions, he answered: HOURS WORKED are the clock hours in which the operator's Orion session recorded work, measured from session records and never typed; LOCATION and CLAUDE PLAN are reported by the operator's own workstation at session start and shown with when they were reported; the MAPPED AGENT is a record per operator ('not all operators will be mapped to orion, currently sahil and ninad both are mapped to orion'); the HOURLY UPDATES stay, in the detail below the day's card. The box no longer shows the updates themselves.

Every summary names the arc and the pursuit the work belongs to

Ruled 2026-10-02 by ninad -- in force

EVERY SUMMARY NAMES THE ARC AND THE PURSUIT THE WORK BELONGS TO: 'also include the name of the arc / pursuit worked on in every summary..'. READ AS (Orion's reading, not Ninad's words): it binds every summary an Orion operator instance writes -- the hourly operator update (#210), the session handover and the summary given to the operator at the end of a piece of work -- and each item of work in it carries the readable NAME of its arc (and phase) and of its pursuit, the key beside it where useful; work that sits in no arc or pursuit says so in those words rather than leaving the names out.

The Operator Instance Log's token line is dark, unbroken and smoother, and an operator's compliance issues show at the top of their card below

Ruled 2026-10-02 by ninad -- in force

THE OPERATOR INSTANCE LOG'S TOKEN LINE IS DARK, UNBROKEN AND SMOOTHER, AND AN OPERATOR'S COMPLIANCE ISSUES SHOW AT THE TOP OF THEIR CARD BELOW (Ninad, CLI-669, 2026-10-02). His words: "in the operator instance log app 1. Tokens consumed (right axis, one scale for every operator) - this should be a dark blue or a dark red, and there should not be gaps, also the line should be smoother 2. Compliance issues should be displayed in the card below on the top, instead of displaying in the top operator box 3. Address the issues for my operator non compliance". READ AS (Orion's reading, not Ninad's words): (1) the line is dark BLUE -- of his two choices the one that keeps red for what red already means on this page, non-compliance; the darkest blue still readable on the page's dark surface (contrast 3:1). (2) 'no gaps': the line runs unbroken from the month's first reading to its last, joining the readings either side of a day that has none; such a day gets NO point and NO value -- never drawn at zero -- and its tooltip and table still say why it has no reading (cookbook 1215: unmeasured is never zero). This retires in place design 690 v1.4's 'a day with no figure breaks the line'. (3) 'smoother': one curve through every reading whose slope runs on through each point instead of flattening at it, and which never overshoots between two readings (so never below zero). (4) the box keeps its colour and its state word; the findings themselves move to the top of that operator's card in the panel below. (5) item 3 is the operator's own compliance, judged by the one composer (communications #275) -- cured at its causes, never by marking a check passed or closing old sessions by hand.

An operator box's compliance is said by its label, never by the box's border or background

Ruled 2026-10-04 by ninad -- in force

Ninad's words (CLI-683, 2026-10-04): 'since the operator box already shows the label non compliant, no need of the red background and border on the non compliant operator box itself'. Asked whether the amber dashed border on a 'not proven' box should go too, or only the red on a non-compliant one, he answered: 'Both go' (the option put: 'Every box looks the same; only its label says compliant, non-compliant or not proven'). READ AS (Orion, marked apart from the ruling): on the Operator Instance Log's landing, an operator's box carries no state colour in its border or background -- breach and not proven alike; the state is said by the box's label, which keeps its colour; communications #275 stands (any non-compliance still shows on the operator's box, now through its red label); the compliance card shown inside an opened box is not the box and is unchanged.

📖Cost Center

Track budget sizing

Ruled 2026-09-14 by ninad -- in force

Every non-pipeline service track carries ~20% surplus over its average active-day consumption, measured over the last 30 days (Ninad chose the month window over week/fortnight/all-time). Pipeline tracks move only by their own rulings. A spike day refuses by design; the day-scoped exception is the lever for a genuine one-off heavy day.

Daily Spend chart axis headroom

Ruled 2026-09-14 by ninad -- in force

Both axes of the Token Cost Tracker's Daily Spend (last 14d) chart scale to 20% above their biggest displayed day: the consumption axis in both display modes, and the initiatives-worked count axis. The fixed 30/30 pairing of is retired in place.

Configurable build-time expense tariff

Ruled 2026-09-15 by ninad -- in force

The canonical rate register retains dated changes and their provenance; historical days use their effective rate. This is a build-time expense tariff, separate from token costs.

Actual-cost basis for configurable infrastructure tariffs

Ruled 2026-09-15 by ninad -- in force

Ninad prefers the configured infrastructure tariff based on actual costs, remaining configurable. Preserve dated rates, actual-cost source, currency and allocation evidence; do not use an invented price or duplicate bundled costs.

Project billing at actual cost

Ruled 2026-09-16 by ninad -- in force

Every project is billed on the ACTUAL costs it incurred: metered usage as metered, flat-plan subscriptions at their fee (allocated by each project's share of plan usage when shared), infrastructure and build effort from the owned-estate records. Invoices are issued monthly and emailed to the project's admins, and a portal shows cost incurred to date. The billing budget line sits under Cost Center, owned by Midas. Sales keeps pricing: any tariff above cost is Sales' decision, never the invoice's.

Invoices are documents: PDF download and a formatted email with the PDF attached

Ruled 2026-09-17 by ninad -- in force

Every monthly project invoice is downloadable as a PDF from the Billing portal, and the monthly invoice email carries that PDF as an attachment. The email is well formatted and states the billing month in words and the amount billed for the month (one amount per currency) in its subject and at the top of its body. The PDF, the email body and the portal download are rendered from the invoice's frozen record by one document, so they never disagree; delivery and payment state are shown in the portal, never written into the document; only a void marks it. A copy sent later (on request or to test) says it is a copy and changes nothing on the invoice. Clicking an app's header returns to that app's own home, never Carol's Apps (design #178 4a).

Procurement is a track of the Cost Center owned by Marco; the Core track is named Budget Control

Ruled 2026-09-17 by ninad -- in force

Ninad ruled in operator session CLI-458 (2026-09-17). PROCUREMENT is a TRACK of the Cost Center, not a service of its own: asked 'should procurement be a new service or a track in existing service?' and shown both, his instruction was 'make marco track owner of procurement'. The track is owned by MARCO, Head of Procurement, a new agent created through Athena's onboarding track and placed under MIDAS in the Finance sub-department - Ninad raised that Cassius 'already has 5 reporting to him, marco will be the 6th', and accepted the placement under Midas ('good idea!'). The operator and the auditor of a function stay different agents: Marco recommends purchases, Themis audits them. The track decides what the estate buys BEFORE money is committed and tracks renewals; it does not set or police spending limits and does not charge projects. In the same instruction the Cost Center's CORE track is named for what it does: 'rename core to something intuitive - like budget or something'; offered Budget Control, Budget and Spend Control, he chose BUDGET CONTROL. The rename is the display name only - the key cost-center-core never changes. If procurement is later offered to client projects, or needs a roadmap Midas should not steer, promoting it to its own service is a new ruling; the track key would stay.

Subscriptions belong to Procurement: the Model Subscriptions app and the droids that feed it move to Marco

Ruled 2026-09-17 by ninad -- in force

Ninad ruled in operator session CLI-468 (2026-09-17), planning the procurement arc: 'droids that are responsible for the subscription app should also be moved over.. plus - anything else to make procurement a proper function'. Shown that the working notes of ruling #37 (cookbook 1764) list balances under Midas's Budget Control track, and asked to confirm that the Subscription Balance Reader moves to Marco, he answered 'Balances --> ok'. So: the Model Subscriptions app, the Subscription Balance Reader that feeds it, and the Credit Watch that runs inside that reader are PROCUREMENT work - owned by Marco, run under his own login, bound to a task of their own on the track cost-center-procurement. Knowing what the estate subscribes to, what each plan costs, when it renews and how much of it is left is part of deciding what the estate buys. Budget Control keeps what ruling #37 gave it - spending limits, the budget change journal, morning funding, the undeclared-spend watch, the compliance verdict, the catalogue export - and READS the balances Marco's reader records; it no longer owns reading them. Ruling #37 stands in full: it never placed balances, only cookbook 1764's description of what it left behind did, and that description is amended. Until the move is built the reader keeps running as Midas's; the ruling is deliberately ahead of the code.

The procurement register covers everything the estate pays for

Ruled 2026-09-17 by ninad -- in force

Ninad ruled in operator session CLI-468 (2026-09-17). Asked whether Marco's register should cover everything the estate pays for or only the AI subscriptions, he answered 'Register scope --> everything'. So the register is one record of every vendor, plan, contract and paid service the estate depends on - the AI model plans and metered accounts already on record, and equally the cloud hosting, the network edge, domains, messaging channels, mail, media tools and anything else paid for - each with what it is for, what it costs, in which currency, how it is paid and when it renews or expires. A fact not yet known is recorded as unknown, never guessed. The subscriptions already on record are part of that register, never copied into a second home (cookbook 1126).

Marco is on top of every purchase, and takes Ninad's approval himself by email

Ruled 2026-09-17 by ninad -- in force

Ninad ruled in operator session CLI-468 (2026-09-17). Offered 'you approve each purchase by email reply to Marco, the same way Athena takes your approval for new agents', he answered 'yes, that is a good idea.. i want marco to me on top of every purchase' (read: to be on top of every purchase). So: every purchase the estate makes has a recommendation of Marco's behind it and Ninad's approval of that recommendation, asked for by Marco in his own name by email and read from Ninad's verified reply in that thread - no approve verb, no mediation, the same shape as the agent onboarding approval (agent-resources #36). Agents never pay: Ninad pays, and Marco records the purchase against the approval. Being on top of every purchase also means Marco finds the ones that did not come through him: a payment, top-up, new plan or vendor call with no approved purchase behind it is named by Marco and raised, never silently absorbed. Marco recommends, Ninad approves, Midas governs the money once it is committed, Themis audits (ruling #37's separation stands).

A subscription the balance reader holds no credential for is named, never a failed run

Ruled 2026-09-18 by ninad -- in force

Asked (CLI-478, 2026-09-18) whether Marco's Subscription Balance Reader should fail every run for a configured vendor nobody ever signed in to on this machine (the OpenAI platform session), or name it without failing, Ninad chose: NAME IT, DON'T FAIL. Every run names each such vendor as 'not set up on this machine' with the reason, the vendor stays visible on every money surface as unset (configured=False with its stale reason), and the missing sign-in is a PROCUREMENT gap for Marco to close - never a reason to hold the process red for ever, which would stop the failing-process alarm from showing any new fault. A vendor whose credential EXISTS and does not answer - including a sign-in that has lost its token - still FAILS the run by name, and a run that reads nothing still fails. Never-set-up is recognised from the exception's class, never from the wording of a message (cookbook 1721). Built as; supersedes the 'records the unreadable ones as a failed run' clause of 's first criterion.

Subscription allocation: pipeline on Codex, media on the GPT API, everything else on the Claude API

Ruled 2026-09-18 by ninad -- in force

Three-way subscription allocation, ruled by Ninad on 2026-09-18 (CLI-483). (1) THE PIPELINE TRACKS RUN ON CODEX: initiatives-planner, initiatives-planner-escalated, initiatives-albus-bypass and initiatives-troubleshooting -- the repair track included, because cookbook 1715 funds it level with the planner and scopes it planner-only, so it belongs on the same subscription as the thing it repairs. (2) IMAGE, VIDEO AND SOUND RUN ON THE GPT API: the four image tracks and the one speech track already do; the two video tracks move off Gemini and LTX once Sora is registered and priced, because an unpriced media combination books as UNMEASURED (rule 3923) and a lane must be certified for what the track does before it carries it (rule 1369). (3) EVERYTHING ELSE RUNS ON THE CLAUDE API, the metered Anthropic lane -- 51 tracks, including the five that declared no lane at all, which get a DECLARED one rather than a fleet default. THE OPERATOR BYPASS IS EXCEPTED BY NAME and stays on the Claude AI (Max) plan: that lane is Ninad's own CLI, not autonomous work, which is why the plan is recorded as a personal tool cost and the track is budget-exempt. This is an allocation DECISION, not a standing rule binding any track to any subscription -- cookbook 1681 stands, and Ninad restated it on 2026-09-18 as 'the only rule regarding the tracks running on models is that there is no rule'. It may be re-decided whenever the balances or the requirements change.

Who pays to register a track on a slot

Ruled 2026-09-20 by ninad -- in force

PROCUREMENT BEARS THE COST OF REGISTERING A TRACK ON A SLOT (Ninad, 2026-09-20,
operator CLI, CLI-485). Asked which service offers slot swapping, Ninad ruled that service
bears the cost: "what service offers model (slot) swapping? it should bear this cost."

THE PAYER IS THE PROCUREMENT TRACK of the Cost Center, owned by Marco -- not the track being
tested. This follows the estate's own allocation rule, that the ACTIVITY decides the track and
never the doer (cookbook 1035). Choosing which subscription a track runs on is a buying
decision, and by Ninad's 2026-09-17 ruling subscriptions belong to Procurement and its register
covers everything paid for. The track being registered does not choose to move; the estate does.

WHAT THIS REPLACES. Until now a registration would have drawn on the TRACK'S OWN verification
Measured

of its four functions came back UNPROVEN on a budget refusal, while that track's working budget
Registering all 51 tracks waiting on the Claude API is a one-off of

THE VERIFICATION ALLOWANCE IS NOT RETIRED. It keeps the job it was sized for -- the automatic
liveness ping that asks whether a slot is alive, about two cents a call. Only REGISTRATION, the
test drive that makes a track do its real work in a candidate slot, moves to Procurement. Two
different activities, two payers; collapsing them is what created this problem.

Funding the one-off registration of tracks on a new slot

Ruled 2026-09-20 by ninad -- in force

The one-off cost of registering the estate's tracks on a new slot is EXCEPTION on Marco's Procurement track, set for the day the registration run happens and CLEARED when it is done -- never by permanently raising his standing cap, and never by spreading the run thin enough to fit inside it. Ninad chose this over both alternatives when shown their cost (CLI-491, 2026-09-20).

WHY SPREADING IS REFUSED: it makes the API lane move wait about ten days on a step that is not the point of the arc.

THE EXCEPTION IS DAY-SCOPED BY CONSTRUCTION -- it auto-reverts the next day -- so it cannot silently become a permanent widening. Setting one and leaving it standing with nothing spending it, or clearing it without naming who and why (cookbook 1763), each defeat the reason this shape was chosen.

What a registration must prove: the track's own work, never the slot's generic abilities

Ruled 2026-09-22 by ninad -- in force

A track is registered on a slot only when the registration exercised THAT TRACK'S OWN WORK. The four generic abilities the registration tool ships with -- answering in prose, returning strict JSON, obeying an exact-output instruction, recalling a fact from a long prompt stack -- are properties of the SLOT, not of the track, and a registration built on them alone is refused. Ninad ruled this when shown the cheaper alternative and its price (CLI-502, 2026-09-22).

He chose instead that no track is registered until something drives its own work end to end, even though that makes the API lane move wait on 56 pieces of work.

WHAT WOULD UNDO IT: shipping a generic probe set as a default for tracks that declare nothing, letting a track inherit another track's declaration, or reading a slot-level liveness result as evidence about a track. Undeclared stays zero, and a functionality that could not be exercised stays UNPROVEN -- never read as safe.

A track with no model work moves without a registration, and the record says why

Ruled 2026-09-22 by ninad -- in force

A track that does no model work is MOVED to a new slot without a registration, and the record says so in those words: it has no work to exercise. It is never recorded as registered, never reads as SAFE, and the first time such a track does real model work it must be registered before it runs. Ninad ruled this on 2026-09-22 (CLI-502) when shown the three ways it could go.

WHY IT WAS ASKED. Registration means exercising the track's own work in the slot (cost-center #78). A track with no model work has nothing to exercise, so 'undeclared is zero' would leave it permanently unregisterable -- and since a track may run in a slot only where it is registered, permanently unmovable. Measured at the ruling: of the 56 tracks due to move off the Claude Max plan, 42 had spent model money in the previous 30 days and 14 had spent nothing at all. Those 14 would have been stranded on the old plan indefinitely, and the estate would have been split across two accounts with no path to closing the gap.

WHY THE OTHER TWO WERE DECLINED. Holding the 14 until they have work leaves the estate split across two subscriptions for as long as a track stays quiet, which may be forever. Giving them a minimal proof through the estate's shared model door is the generic-ability shape refused in cost-center #78, one level along: it would answer a question about the SLOT and file it as a fact about the track.

WHAT MUST NOT COLLAPSE. 'No model work to exercise' is a THIRD state beside registered and unregistered, and it is not a quiet pass: any reader asking whether this track is proven in this slot gets no for an answer, with the reason. It is judged per (track, slot) like a registration, because a track that gains model work has gained it everywhere. Folding it into 'registered' to make a count look complete, treating it as a standing exemption that survives the track starting to do work, or inferring it from a quiet week rather than from the absence of model work all look like tidying and each undoes the ruling.

HOW IT IS DECIDED. From whether the track has model work at all, never from recent quiet: a dormant track that does model work when it runs is an ordinary track awaiting registration, not a track with nothing to prove.

A registration is proved by several runs, and one bad run decides it

Ruled 2026-09-22 by ninad -- in force

A registration probe is exercised SEVERAL times and every run must pass; a single failing run is the verdict and ends the sampling. Ninad ruled it in those terms on 2026-09-22 (CLI-505): 'use multiple calls to be sure.' The reason the asymmetry is deliberate: one bad answer is real evidence of a fault, while one good answer proves only that the slot behaved once and can never establish the ABSENCE of a behaviour. It was measured -- agent-resources-sam-chat failed the reply-gate probe on anthropic/claude-opus-5, passed the same probe on the subscription it already runs on, and on repeat failed twice in three runs, while four chat tracks had been recorded SAFE on one sample each. The sample count lives in ONE place, the registration tool, so no probe carries its own definition of how it is counted, and the verdict's reason says how many runs stood behind it. Taking the best run, averaging them, adding a flag that lowers the count to save money, or continuing to sample after a fault has been seen, each turn a strict check into a lenient one -- which is what this registration exists to prevent. Where a larger sample would cost materially more, the figure goes to Ninad and the count is not chosen alone.

Unmeasurable spend: estimate it, scope the refusal, abort early, and raise it

Ruled 2026-09-23 by ninad -- in force

AN UNMEASURABLE CALL IS ESTIMATED, NEVER ZEROED, AND ONE BAD ROW MAY NOT STOP EVERY TRACK (Ninad 2026-09-23, CLI-525). One Codex call that died before reaching the model left a single unmeasurable row against the planner track; because an unmeasurable row makes the whole day's estate total unmeasurable, all 63 tracks refused to spend for about 13 hours and two of Elrond's and Albus's droids failed every run behind it. FOUR THINGS ARE RULED. (1) SCOPE THE REFUSAL: an unmeasurable row refuses the TRACK it belongs to; every other track keeps working, against an estate figure declared a LOWER BOUND rather than a measurement. (2) ESTIMATE, NEVER ZERO: an aborted call CAN have spent, so it carries an ESTIMATED value with its basis - Orion proposed recording it as a measured zero on the evidence of no rounds and no tokens, and Ninad refused that: 'aborted call can spend, so give an estimated value to the aborted call'. A zero asserts a measurement nobody made and is believed by every reader; an estimate is honest and can be corrected. This NARROWS 's known-cost-of-nothing cases rather than widening them. (3) ABORT EARLY: a call that cannot complete is aborted as soon as it can be known to be failing, rather than being allowed to run on and leave a blank behind it. (4) SAY SO OUT LOUD: when this happens Elrond raises an EMAIL notification and an ESCALATION to Orion. The 13-hour outage was silent on both counts - the board showed it only to a session that ran the board.

Carolopedia's write-ups are paid from a track of their own

Ruled 2026-09-24 by ninad -- in force

Ninad, 2026-09-24 (CLI-535). Offered three ways to pay for Carolopedia's written write-ups (governance #104) -- a budget of their own, a trickle inside the shared governance budget, or Bilbo's small Carolopedia budget -- he chose a budget of their own. So the writing is its own track in Bilbo's Blogs service, which owns Carolopedia, with a standing daily budget for upkeep and a dated budget exception while the backlog is written, cleared when it is done. The shared governance budget is not spent on it.

The OpenAI platform (GPT API) subscription is retired

Ruled 2026-09-25 by ninad -- in force

The OpenAI platform account the estate held for GPT API text work is RETIRED: it has been out of credit since 2026-09-19 and no text work routes to it. The subscription record is retired in place, never deleted, and the Subscription Balance Reader reads only subscriptions the estate holds, so the OpenAI platform account and the long-retired DeepSeek come off its list. Any image or media lane that reaches OpenAI through a key of its own is NOT part of this retirement and keeps working. WHAT LOOKS LIKE A FIX AND IS NOT: topping the account up so the reader reads green; deleting the subscription record; retiring an image lane along with it.

Effort estimation bills Elrond's Build Governance line

Ruled 2026-09-25 by ninad -- in force

Sizing the effort of initiative attempts is Elrond's activity and bills his one line, Build Governance (initiatives-build-governance), through its task initiatives.effort_estimation. Acceptance and sizing now draw on the same line: Ninad chose to fold both of Elrond's small lines into his one track (CLI-560).

An adapter layer sits between tracks and slots, so slots and tracks switch seamlessly

Ruled 2026-09-25 by ninad -- in force

AN ADAPTER LAYER SITS BETWEEN THE TRACKS AND THE SLOTS, SO THAT IT CAN SEAMLESSLY FACILITATE THE SWITCHING OF SLOTS AND TRACKS (Ninad, 2026-09-26, CLI-563, in his words: 'the principle is to have an adaptor layer between the tracks and slots, so that it can seamlessly facilitate the switching of slots and tracks'). Given when Orion reported that no design said how an agent's OS login reaches its slot's sign-in: Albus's bypass lane had moved to his own login (security #150) and every Codex call from that login was refused, while Forge's login worked. ORION'S READING, recorded as his and not as the ruling's words: the adapter layer -- not the calling login, not a per-login setup -- is what connects a track to its slot, including the sign-in the slot needs; so which login a droid runs under, or which track it serves, can never decide whether it reaches its slot, and moving either needs no connection work. Rebuilt on this: design 682 v1.1. What looks like a fix and is not: preparing each login's own sign-in by hand, moving a lane back to whichever login happens to work, or a caller naming a provider, model or credential path instead of its track.

The adapter layer is isolated from both tracks and slots, and every slot joins it by one pattern

Ruled 2026-09-27 by ninad -- in force

THE ADAPTER LAYER IS ISOLATED FROM BOTH TRACKS AND SLOTS, AND EVERY SLOT JOINS IT BY ONE PATTERN (Ninad, 2026-09-27, CLI-574). Asked, after the estate's Codex sign-in was found with its renewal spent by a holder other than its keeper, in his words: 'find the best architectural fix to this issue, so that the adaptor layer that connects the slots to the tracks is isolated from both tracks and slots, and follows a consisten design pattern across all slot registrations', he approved Orion's six-part answer ('approved, build an arc for this'): (1) A SLOT IS ITS OWN RECORD -- subscription, model, adapter, keeper and state -- and a track points at one slot and knows nothing else about it. (2) EVERY ADAPTER KEEPS ONE CONTRACT whatever its vendor, image, voice and video included: resolve the model, obtain a call-only sign-in, make the call, name a refusal, prove itself, and renew (the keeper alone). (3) A SUBSCRIPTION'S FULL SIGN-IN IS READABLE BY ITS KEEPER LOGIN ALONE; every other login is handed, through ONE sign-in door that learns who is calling from the operating system, a call-only sign-in that can make calls and can never renew. (4) THE KEEPER RENEWS EVERY RENEWING SIGN-IN DAILY AND CHECKS EVERY FIXED KEY DAILY, so a spent renewal is found within a day. (5) THE MODEL FOR A CALL IS CHOSEN ONLY BY WORK -> THE TRACK IT SERVES -> THAT TRACK'S SLOT; per-droid pins, the chat, consciousness and Orion lanes and the fleet default become ordinary tracks (design 682 guarantee 1). (6) EVERY SLOT ENTERS THE ESTATE BY ONE PATH -- declared, sign-in enrolled, keeper-proven, each login proven, tracks registered, live -- and the door refuses a track not registered on the slot. ORDER, as approved: the sign-in held by its keeper alone lands BEFORE the estate's fresh Codex sign-in, or the new sign-in can be spent the same way. ORION'S READING, recorded as his and not as the ruling's words: a sign-in is made FOR the keeper on the machine and never copied from another machine, because two machines holding one renewal chain cut each other off; and the keeper login may run only code no estate login can edit, or isolating the sign-in to it isolates nothing. What looks like a fix and is not: re-copying a laptop sign-in to the machine; a caller keeping its renewal token 'so it can recover by itself'; an adapter reading a key or sign-in file itself; a second subscription list beside Procurement's register; a default slot for a track that declares none.

The adapter layer and its arc are owned by Marco (Procurement); Radagast operates the keeper and the sign-in door

Ruled 2026-09-27 by ninad -- in force

MARCO OWNS THE ADAPTER LAYER AND ITS ARC (Ninad, 2026-09-27, CLI-574, answering 'should the arc and the layer be owned by midas or marco?' with 'marco'). Offered with Orion's reading: the layer's subject is SLOTS -- a subscription and a model -- and how the estate reaches what it buys; subscriptions moved to Marco's Procurement track on 2026-09-17 and Procurement pays for registering a track on a slot (cost-center #58), while Midas's Budget Control and Billing are about money caps and charges, which the layer does not touch. So: Marco owns the adapter layer (design 682) and arc CAROL-ARC-0029 with all its phases; Radagast OPERATES the sign-in keeper, the sign-in door and slot enrolment for him (a gate the work passes through is not the work's owner); Midas keeps the Cost Center service, its budget caps and billing. The arc skill's convention that an arc sits under its SERVICE's owner gives way here to the owner of the TRACK whose duty of care covers the subject; cookbook 1790 names no owner rule.

Midas sets every governed track's daily budget from the rolling week, 20% above its average, under hard caps

Ruled 2026-09-30 by ninad -- in force

MIDAS ADJUSTS THE BUDGETS DAILY FROM THE ROLLING WEEK (Ninad, CLI-616, 2026-09-30). Shown that the same nine tracks reach their caps every day within the first hours after midnight, Ninad ruled: 'it's important that we enable Midas back the ability to adjust the budgets based on the average usage for the rolling week, so that the caps are not hit.. budget can be 20% more than the average usage of the rolling week per track with a hard cap.. as long as the overall estate budgets are kept in check, individual tracks and services can be adjusted on a daily basis as needed', and then: 'with orion bypass as the exemption, implement the rolling week average + 20% (rounded) budget caps, calculated on a daily basis'. THE FORMULA: every governed track's standing daily budget is its average daily spend over the last seven complete days, plus twenty percent, rounded to whole euros, recomputed every day by Midas's allocator under his own login -- up or down. THE EXEMPTION: the Orion bypass alone stays exempt and uncapped; every other track, the pipeline's lanes and the troubleshooting line included, follows the formula. Where the formula's sum would exceed the estate ceiling, the allocation is scaled back to fit, never the ceiling lifted. This SUPERSEDES the formula of the 2026-09-15 ruling (cookbook 1730: one-and-a-half times the average, never decreased, pipeline lanes untouched), which is retired in place; its reasons -- every track carries a real number, zero is never a standing value for a governed track -- stand.

A one-off boost clears the effort sizing backlog: Elrond's line lifted for two days, the estimator's allowance raised until its list is empty, then both given back

Ruled 2026-09-30 by ninad -- in force

A ONE-OFF boost clears the effort sizing backlog sooner; the standing pacing is otherwise unchanged. This excepts, once, the rule that raising the line or the allowance to speed up sizing undoes #205's pacing; that rule stands for every other day. Leaving the boost in place after the list is empty, or reading this as a standing licence to lift the line, each undo it.

The company's expenses are every subscription, Azure included, and every contract; Midas owns them

Ruled 2026-10-01 by ninad -- in force

The company's expenses, owned by Midas (Cost Center), are EVERY subscription the company pays for -- the model subscriptions already metered AND the infrastructure ones, Azure first -- and EVERY contract the company makes (Saee's internship, Sahil's contractor agreement, and those after them), each a line in the one spend plan and an actual in the company's accounts. A subscription or a contract missing from the register is an expense nobody owns; Marco's registers (subscriptions, contracts) are where each is kept, and Midas's accounts read them.

Midas has access to the company's bank account

Ruled 2026-10-01 by ninad -- in force

Midas, as owner of the company's expenses, has access to the company's bank account: every transaction on it reaches the company's accounts as an actual (a cost or a revenue), reconciled contract registers, so the books are read from the bank and never typed. The access is his own credential, held like a vendor key (through the sign-in keeper and door, cost-center #172), never the administrator's personal banking. The account exists only once the company is registered (leadership #250); until then this ruling is recorded and waits.

Company Accounts shows ACCRUED expense for the whole year, never paid; future months are FORECAST

Ruled 2026-10-01 by ninad -- in force

The Company Accounts app shows what the company has ACCRUED, not what it has paid, for the entire year. A past or current month is the expense accrued from the records: a subscription's plan fee for every month it is active, credit purchases when made, Azure's billed usage, and people from their contract terms and the hours actually worked. Every future month is a FORECAST derived from the same records: active plan fees carried forward, usage-based lanes and Azure at their run rate, contracts at their terms to their end. Every figure says which it is, accrued or forecast, and the year's boxes read accrued to date plus the forecast for the rest of the year. Paid is a separate question, answered by the bank feed (#256), never by this app. Ninad, 2026-10-01 (CLI-633): 'this app should show what is accrued, not paid, for entire year.. future months should be forcasted'.

Every estimation and reading of token consumption uses the same source

Ruled 2026-10-02 by ninad -- superseded 2026-10-02

EVERY ESTIMATION AND READING OF TOKEN CONSUMPTION USES THE SAME SOURCE: 'the estimations of elrond, cost tracker, operator log etc should use the same source for token consumption'. READ AS (Orion's reading, not Ninad's words): one source and one count for every surface and estimator that states how many tokens were consumed -- Elrond's effort estimates and his mileage measure, the cost trackers, the Operator Instance Log and every other reader: the cost ledger, read through ONE definition of a row's tokens (measured 2026-10-02: one ledger but at least five hand-written counts -- input+output+cache reads for the per-initiative totals Elrond's estimates read, input+output for the cost app, fresh input+output+cache reads+cache writes for the daily expense and the Operator Instance Log). A figure about something else -- an agent's carried prompt weight, a vendor's own usage report -- is a different measure and says so; it is not a second count of consumption.

Ended because: Ninad widened it the same evening from 'the same source' to counting AND reporting consistent across the estate

Token consumption is counted and reported the same way across the estate, from one source

Ruled 2026-10-02 by ninad -- in force

TOKEN CONSUMPTION IS COUNTED AND REPORTED THE SAME WAY ACROSS THE WHOLE ESTATE, FROM ONE SOURCE (Ninad, 2026-10-02, CLI-663). His words, in order: 'the estimations of elrond, cost tracker, operator log etc should use the same source for token consumption'; then, shown that the readers use two sources (the cost ledger, and the pipeline's own run records) and at least five counts: 'ok, go ahead, ensure that the counting and reporting of the consumed tokens is consistent across the estate'. READ AS (Orion's reading, not Ninad's words): every estimate, surface and report that states tokens consumed -- Elrond's effort estimates and mileage, the cost trackers, the daily estate expense, the Operator Instance Log, the activity tracker, the initiative audit and monitor, and any other reader -- counts from the ONE cost ledger through ONE definition of a row's tokens, so the same work reads the same number wherever it is shown. A figure about something else (an agent's carried prompt weight; a vendor's own usage report) is a different measure and is named as such, never a second count of consumption.

📖Governance

Carolopedia's appearance

Ruled 2026-09-23 by ninad -- in force

Carolopedia wears the look it had before 2026-09-15, recorded as design 676. Ninad ruled it on 2026-09-23 (CLI-520) in those words: Carolopedia gets the look it previously had before the look changed. The Carol App Design System (design 178) is the chrome for the estate's INTERNAL apps and does not decide Carolopedia's appearance: Carolopedia is a public website, and it already sits on the same slate palette that design names, so a compliance finding against it is about an internal app's furniture, not about the estate's colours. A proposal to re-theme Carolopedia is refused naming this ruling, rather than filed and later discarded. Three such filings were raised by the design-compliance reviewer between 2026-09-15 and 2026-09-17 and every one of them died because its PARENT had closed, so the finding itself was never judged on merit - which is why the same finding kept coming back.

Blocks and tracks are reached only through their service

Ruled 2026-09-23 by ninad -- in force

Ninad, 2026-09-23 (CLI-527): "remove blocks and tracks from the front page, they should only be drill downs in individual services as hyperlinks to their names in the service descriptions."

A block and a track are not things the public encyclopedia lists in their own right. They keep their pages; what is ruled is the WAY IN. No front-page counted card, no front-page section, no navigation entry, and no flat listing -- the one route to a block or a track is the service it belongs to, whose own page names each of its own as a hyperlink.

Derived, never typed: each block publishes its parent service and each track its service, so a block moved to another service moves with it and one whose service is not published is not invented a home. Re-adding the cards, the navigation entries or the flat listings, or hand-writing the per-service list, each undoes this ruling. A block's crumb leads back to its service, never to a listing that no longer answers.

The Carolopedia front page shows no portraits and no link to the full map

Ruled 2026-09-23 by ninad -- in force

Ninad, 2026-09-24 (CLI-535): "hide the carol and orion pics from carolopedia landing page" and "hide the map link from the carolopedia landing page".

The welcome hero keeps its heading, its tagline and its call to action, and carries no portrait of any agent. The embedded Carolverse Map stays on the front page; the link that opens the full map in a new window does not. The agents' own pages keep their portraits, and the full map keeps its own route -- what is ruled is the front page, not the things it used to point at.

This narrows 's restoration of the pre-2026-09-15 front page, which brought both back; that restoration stands in every other respect. It also settles the question CLI-527 left open -- whether the front page keeps its full-map link while is unbuilt. Re-adding either to the front page, as part of restoring an older look or otherwise, undoes this ruling.

Carolopedia withholds only what is a genuine security risk, and agents' own choices

Ruled 2026-09-24 by ninad -- in force

Ninad, 2026-09-24 (CLI-535): "all information on carolopedia is gone.. i had instructed in one of the sessions to hide sensitive information from general public, but what i see is that almost all information is gone.. can you restore back the information and hide only genuinely sensitive information that can pose as a potential security threat to oratorium security".

Governance #12 stands: publication uses explicitly approved public fields, never a process's privileges, and security and privacy outrank completeness. What this ruling settles is WHERE the approved set is drawn: around everything that is not a genuine risk, never around a minimum. Withheld are credentials and keys; personal data about real people; private conversations; wishes; money figures (budgets, spend, balances, investments, earnings); security configuration (operating-system logins, hosts, ports, file paths, addresses, access allow-lists and policies, cloud identities); and live internal work-queue detail (initiative identifiers, run records). Anything that cannot be tied to one of those stays published.

Agent pages honour each agent's own identity choices (cookbook 1521): the public sees the facets an agent holds at the public level, and a facet an agent holds higher is shown as withheld, never overridden by Carolopedia. Offered the choice of overriding them, Ninad chose to honour them.

The written write-ups return: prose is written from the approved public projection alone, so wording can never carry a fact the projection does not, and it is re-checked at delivery like every other published field. Offered a records-only rebuild at no cost, Ninad chose records plus new prose.

Narrowing the approved set back to a minimum, overriding an agent's choice, or publishing a withheld category because an older page once showed it, each undo this ruling.

Every status or state vocabulary is RDM values

Ruled 2026-09-25 by ninad -- in force

Any set of statuses or states the estate shows or records - including states derived at read time and never stored in a column, such as the day chart's band - is an RDM reference set: its values and meanings are onboarded through the reference-data door, the composer checks every value it emits against the set, and a surface shows the recorded meanings carried in its payload rather than words typed into the page. Colours and other presentation may stay in the page, keyed by value.

Roadmap as a registry entity with scoped operator approval

Ruled 2026-09-27 by ninad -- in force

The roadmap is a separate first-class registry entity. Its user-facing format is: strategic ask, service, service task, status, description. Status is governed through RDM with the values proposed, planned, in progress, completed, rejected, discontinued. A proposed item becomes planned only when an operator approves it; work starting makes it in progress; completed work becomes completed. A rejected proposal becomes rejected. If approved work is later cancelled by an operator, it becomes discontinued. Only operators approve roadmap items: only estate operators approve strategic asks; estate operators and service operators approve service tasks within their authority. Clara owns the Carolverse roadmap; service roadmaps are owned by their service leads. This replaces the earlier administrator-only approval authority for strategic asks with estate-operator authority. Ownership is not approval authority. The same operator scope governs rejection and discontinuation of the corresponding ask or task. The requested RDM terminal value is completed (the narrative word complete denotes this value).

A service task's progress is made by its work; a strategic ask's progress is moved by its owners and operators

Ruled 2026-09-27 by ninad -- in force

A roadmap SERVICE TASK moves to in progress and to completed only as its work does: the initiatives that name it, through the one follow-work writer, never a person by hand. Its status vocabulary is its own and records those two moves as made by the work, so the record says what the code does. A STRATEGIC ASK keeps the lifecycle governance #177 set out: its owners and scoped operators move it to in progress and completed. The two kinds are governed by two vocabularies with the same values, one per kind.

📖Infrastructure & Backups

The operating system expires old temp and Trash entries, whichever login owns them

Ruled 2026-09-28 by ninad -- superseded 2026-09-28

THE OPERATING SYSTEM EXPIRES THEM (Ninad, CLI-604, 2026-09-28). Hagrid's clean-up runs under his own login and cannot remove an old entry another login owns: the temp area is sticky, and a Trash folder of the apps login is closed to him. Three Trash items held by the apps login kept his keeper's run failed, and his Daily Janitor had counted thousands of temp entries as removed that were all still there. Shown three ways to remove such entries -- the operating system expires them by a rule only root can change; a narrow removal door for Hagrid; a one-off clean-up with each owner cleaning its own afterwards -- Ninad chose the first: '1. The operating system expires them'. So: a root-owned rule of the operating system's own temp-file service ages entries out of the temp area after three days and out of the two Trash folders of the work tree after fourteen days, whichever login owns them. No login of the estate gains a power to delete another login's files, and the rule is changed only at the root login. Hagrid's keeper and janitor go on removing what their own login can and reporting truthfully; what the operating system expired is not on Hagrid's receipts, and that was stated when the choice was put. The ages are Orion's reading of rulings already made: fourteen days for Trash is design 681 v1.2; three days for the temp area is the figure recommended at CLI-455 on.

Ended because: Trash leaves the operating system's cleaner: it reads each file's own age, not when the thing was trashed, so Trash would stop being a way back; a Trash item Hagrid cannot remove is handed to him instead (Ninad, CLI-604, 2026-09-28)

The operating system expires old temp entries; a Trash item Hagrid cannot remove is handed to him

Ruled 2026-09-28 by ninad -- in force

TRASH STAYS OUT OF THE OPERATING SYSTEM'S CLEANER (Ninad, CLI-604, 2026-09-28, amending his ruling of the same day). The operating system's temp-file service expires entries of the TEMP AREA after three days, whichever login owns them, reading an entry's age from when it was made or changed and never from when it was last read; that rule is changed only at the root login (installed 2026-09-28 21:20 UTC: 6,061 entries removed). The two Trash folders of the work tree are NOT put under that cleaner: it reads each file's own age, not when the thing was trashed, so a folder trashed today holding month-old files would lose them the same night and Trash would stop being a way back. Trash stays Hagrid's, held to fourteen days from when a thing was moved in (design 681 v1.2, Rulings Repo backup #200). A Trash item his login cannot remove, because it holds files of another login, is HANDED TO HIM: an operator gives it to Hagrid's login through a narrow operator door that accepts only an item lying in one of the two Trash folders, follows no link and removes nothing itself, and Hagrid's keeper removes it on its next run and says so on its receipt. Until the door is built such an item is given to him in a root step, as three were on 2026-09-28. Shown the recommendation with its reason, Ninad answered: 'I agree with your recommendations'.

📖Leadership

Fundraising holds the plan, never the actuals

Ruled 2026-09-22 by ninad -- in force

The Fundraising app showcases the PLAN: what the venture intends to raise, at what shape, what each cycle buys and the runway it funds. What has actually been committed is a different question and this is not its home. The stored `raised_eur` column is RETIRED IN PLACE -- kept so nothing recorded is destroyed, refused BY NAME at the door, and read by no surface. Hiding it on the page alone would leave Clara's registrar able to record an actual into an app that promises not to hold one.

The Fundraising app opens on the estate's own project, derived

Ruled 2026-09-22 by ninad -- in force

The project shown by default is DERIVED from the dominion record's base project, never the word 'carolverse' written into the app: naming it leaves every forked dominion opening on somebody else's project. A viewer who cannot reach the base project is given NO default rather than another project, and an explicit choice always wins.

The Fundraising app presents three tabs, and the share split is derived

Ruled 2026-09-22 by ninad -- in force

Three main tabs: the five-year plan (valuation, ARR and cost at each year end), the fundraising cycles (amount to be raised, with the founders' and investors' share at the end of each round), and the spend distribution for the raised capital. THE SHARES ARE DERIVED from each cycle's pre-money and raise and are never stored beside them -- a stored percentage is the same fact twice and drifts the moment either figure is revised. A cycle missing its valuation or its amount makes ITS split and EVERY LATER cycle's UNMEASURED: the chain cannot resume across a gap, and no percentage is ever guessed or shown as zero.

The fundraising figures are the administrator's decision and are never seeded

Ruled 2026-09-22 by ninad -- in force

The rounds, the five-year plan and the spend distribution ship EMPTY and stay empty until Ninad decides them. Seeding a plausible curve, cycle or spend split would be indistinguishable from a decision he had made, which is the one thing these records exist to state. Regression tests lock all three tables at zero rows. Those are inputs to a decision, never the decision.

Where the ownership split is shown in Fundraising

Ruled 2026-09-23 by ninad -- in force

The split between the founders, the founding investors and the later investors is shown as a chart in a card ON THE PAGE -- its own always-rendered section, never inside a tab panel a reader has to open first. The Fundraising cycles table carries the MONEY of each cycle (what it raises and what the company is worth once it closes) and no longer carries the three percentage columns, because the card below plots exactly those rows. The five-year plan table keeps its two share columns: it places the split on YEARS while the card places it on ROUNDS, so those rows are not shown below. Because the figures left the table, the card carries its own small table of them -- a percentage reachable only by hovering is gated, and the tooltip is never the only home of a value.

How the ownership curve is drawn

Ruled 2026-09-23 by ninad -- in force

The lines are drawn visibly CURVED, not as straight segments between the cycles -- 'make the chart lines smooth and curved rather than straight'. The curvature is judged by eye, so an interpolation that is a cubic by construction but hugs the straight line does not satisfy this: monotone cubic was tried and drew a polyline, because it takes its slope at each point from the average of the neighbouring secants. At the same time the curve may NEVER overshoot: no point of it may leave the two values it joins, and none may read above a hundred or below nought per cent, because a bulge between two cycles states a share nobody holds. Both hold together by putting each segment's two control points at its horizontal midpoint, one at each end's height -- the curve then lies inside the convex hull of points that are all within the band. Replacing this with a Catmull-Rom or tensioned spline to get a livelier line reintroduces the overshoot.

Investor onboarding is shown by Clara's own lean Investor Onboarding app

Ruled 2026-09-30 by ninad -- in force

Investor onboarding is shown by Clara's own Investor Onboarding app: a lean app that only displays the investor onboarding pass, owned by Clara on the Finance track, under its own access policies. Asked on 2026-09-30 (CLI-623) whether Clara's display of the pass should be a tab in her Fundraising app, whose three tabs are ruled (leadership #85), or a lean investor onboarding app of her own, the administrator answered: 'investor onboarding app of her own'. This applies agent-resources #220 (each owner's onboarding is shown by that owner's own app) to the investor kind: the pass lives once in the canonical library, the workflow is Clara's, and the app performs nothing (cookbook 1710). Adding the investor pass to the Fundraising app, or to Athena's, Leo's or Jarvis's onboarding app, undoes this ruling.

Investors get a monthly update and a weekly showcase; the investor pass stays a draft

Ruled 2026-09-30 by ninad -- in force

Investors hear from the company on two rhythms, both written by Clara from her own address: a MONTHLY investor update, and a WEEKLY communication showcasing interesting updates about the company. Asked on 2026-09-30 (CLI-627) the four decisions the draft investor onboarding pass needs, the administrator answered: 'keep the current process as draft.. monthly updates to investors is ok, i think, but there should be weekly communications as well, showcasing interesting updates about the company'. So the cadence decision is settled as monthly plus weekly, and the pass is NOT approved: it stays a draft, its proposed Finance-track tasks stay undeclared (cookbook 1199), and nothing in it runs until the administrator approves it. The weekly communication is a showcase, not a second monthly update. Dropping the weekly communication, folding it into the monthly update, sending either from the administrator's or Carol's address (cookbook 1809), or declaring the tasks so the pass can start before it is approved, each undoes this ruling.

An investor is its own kind of person, gets in only through the investor onboarding pass, and sees the Data Room read-only and nothing else

Ruled 2026-09-30 by ninad -- in force

Asked on 2026-09-30 (CLI-627) the decisions the draft investor onboarding pass still owed, the administrator answered: '1. investor is its own kind of person, separate from users and operators 2. readonly access to dataroom is correct 3. they get in as per the onboarding process 4. all investor records should be first class registry entries'. AN INVESTOR IS ITS OWN KIND OF PERSON: neither a user (served by the estate, Jarvis's) nor an operator (working for the estate, Athena's). An investor gets in ONLY through the investor onboarding pass -- admitted by the administrator, then granted access by the pass's own steps -- and what an investor is granted is named, READ-ONLY access to the Data Room and nothing else in the estate. Recording an investor as a user or an operator so an existing door lets them in, granting any write, or granting anything beyond the Data Room, each undoes this ruling.

Every investor record is a first-class registry entry

Ruled 2026-09-30 by ninad -- in force

Asked on 2026-09-30 (CLI-627) the decisions the draft investor onboarding pass still owed, the administrator answered: '1. investor is its own kind of person, separate from users and operators 2. readonly access to dataroom is correct 3. they get in as per the onboarding process 4. all investor records should be first class registry entries'. EVERY INVESTOR RECORD IS A FIRST-CLASS REGISTRY ENTRY: the investor itself and every record the investor pass keeps about them (admission, Data Room access, questions and answers, commitments, updates sent) live in the registry as entries of their own, written through one door and journalled like every registry fact (cookbook 1504). The CRM's investments pipeline, the Data Room and every app REFERENCE those entries and never hold a copy (cookbook 1126). Keeping an investor only as a CRM lead or contact, as a note or flag on a person or user row, in an app's own store or in a side file, each undoes this ruling.

An investor's status follows the onboarding pass: lead, admitted, in diligence, committed, invested, declined, withdrawn

Ruled 2026-09-30 by ninad -- in force

An investor's status is one of seven governed values, following the investor onboarding pass: LEAD (introduced and recorded, phase A), ADMITTED (the administrator admitted them; the Data Room is open to them read-only, phase B), IN DILIGENCE (reading the Data Room and asking questions, phase C), COMMITTED (terms agreed and documents signed, phase D), INVESTED (the money arrived; they receive the monthly update and the weekly showcase, phase E), DECLINED (either side said no; the record is kept) and WITHDRAWN (they left after investing; the record is kept). Proposed by Orion on 2026-09-30 (CLI-627) for and answered by the administrator: 'sounds good to me'. The values live in reference data (cookbook 4236) and are enforced at the registry's write seam; an investor's record is never deleted, so declined and withdrawn are statuses, not removals. Typing the list into code, adding a status without a ruling, or deleting a declined or withdrawn investor each undoes this ruling.

Investors in diligence receive the weekly showcase too, and it carries only what is public

Ruled 2026-09-30 by ninad -- in force

Investors still in diligence receive the weekly showcase too. The weekly showcase (leadership #233) goes out from the diligence phase of the investor onboarding pass (phase C) onward, and carries on after they invest; because it reaches people who have not invested, it carries ONLY what is public -- never what the Data Room holds, never figures or plans that are not published. Asked on 2026-09-30 (CLI-627): 'should investors still in diligence get the weekly showcase too? If yes, it can only carry public news; if no, it starts once they've invested and can share what the Data Room holds' -- the administrator answered 'yes'. The monthly update is unchanged: it starts when they have invested. Holding the showcase back until investment, or putting Data Room material into it, each undoes this ruling.

The investment chain may be spread across services, as long as it holds together

Ruled 2026-09-30 by ninad -- in force

The investment chain -- valuation, investment plan, spend plan, roadmap, balance sheet and profit and loss, shareholding and press communications -- may be spread across services, each part with the service whose duty covers it, as long as it all holds together: one pursuit carries the chain end to end and one registered check proves every link. Finance stays a track exclusive to Clara (cookbook 1724 stands). Ninad: If its distributed across services, that is also fine with me.. as long as it all holds together..

Denken Labs is registered in the United Kingdom

Ruled 2026-10-01 by ninad -- in force

Denken Labs is registered as a company in the United Kingdom. Its registration options there (legal form, the part of the United Kingdom it is registered in, registered office, directors, fees, duties) are laid out by Clara for the administrator's decision under, and the company's contracts, certificates and templates are written for the law that registration names. Until registration completes, a document names the company as in formation and says who signs for it.

📖Marketing

The Carolverse video channel links back to the estate: every video description and the channel's About text

Ruled 2026-10-02 by ninad -- in force

Asked: 'For the visibility work, may I edit the YouTube channel? All 99 videos are public and none links the Carolverse landing page (61 have no links at all). The plan: add a short closing block to every video description linking Carolopedia, the Logbook and the landing page, keep a backup of each original, and replace the channel's About text with the Carolverse sentence plus the landing link.' Ninad answered: 'Yes, do both'. READ AS: the closing block (composed from the public-property record by shared.public_readme) ends every Carolverse video description, existing and new, and the channel's About text is the public Carolverse sentence plus that block.

Every public HOMEPAGE names Carolverse and says what it is; YouTube's page and estate sub-pages are not counted

Ruled 2026-10-02 by ninad -- superseded 2026-10-04

Asked: 'The page-identity item's last check says every public property must name Carolverse. As written, that includes YouTube's own channel page and three small estate pages (Agent Escalations, Carol's bio, the Map), not just the homepages. Which should count?' Options: 'Homepages only -- the five estate homepages, plus the company site once its address works; YouTube's page and the three small pages are left out' or 'All ten properties'. Ninad answered: 'Homepages only'. Asked in the same sitting: 'Google's Rich Results Test has no way for me to run it automatically ... How do we settle Google's half?' Ninad answered: 'I'll run it by hand'. READ AS: the daily crawl-readiness reading must find Carolverse named for the Carolverse OS landing, Carolopedia, the Logbook, Oratorium, Carol's landing and the company site once it resolves; YouTube's channel page and the estate's sub-pages are not held to it. Google's Rich Results Test stays a criterion and is run by the administrator by hand, one run per homepage.

Ended because: CLI-684: #289 counted 'the company site' when CLI-670 believed it was the Denken Agents page; it is the DenkenLabs landing, and Ninad ruled it keeps its own title.

Every estate HOMEPAGE names Carolverse and says what it is; the company site keeps its own title and carries robots, a sitemap and Organization data linking it to Carolverse

Ruled 2026-10-04 by ninad -- in force

Carried from #289 unchanged: asked (CLI-670) which properties must name Carolverse, Ninad answered 'Homepages only' -- the five estate homepages, YouTube's channel page and the estate's sub-pages (Agent Escalations, Carol's bio, the Map) not counted -- and asked how Google's half is settled, 'I'll run it by hand'. Asked: 'Your earlier ruling says every public homepage must name Carolverse in its title and first paragraph, "plus the company site" -- but that was written when we thought the company site was the Denken Agents page. denken-labs.com is actually the DenkenLabs research-commercialisation page. Must it name Carolverse too?' Options: 'No, keep its own title (Recommended) -- DenkenLabs keeps its research-commercialisation title and first paragraph; it still gets a robots file, a sitemap and structured data naming Denken Labs as the company behind Carolverse, so search engines link the two' or 'Yes, name Carolverse'. Ninad answered: 'No, keep its own title'. READ AS: the daily crawl-readiness reading must find Carolverse named in title and first paragraph for the Carolverse OS landing, Carolopedia, the Logbook, Oratorium and Carol's landing; the company site denken-labs.com is NOT held to it and keeps its own title and first paragraph; it gets robots.txt naming its sitemap, a sitemap.xml, and Organization structured data for Denken Labs that names Carolverse as its own, so the company and Carolverse are linked for search engines. Google's Rich Results Test stays a criterion, run by the administrator by hand, one run per homepage (the company site's once its structured data is live).

📖Sales

Glover is a service extension of Sales, never a project

Ruled 2026-09-14 by ninad -- in force

GLOVER WAS NEVER A PROJECT (Ninad, CLI-416, 2026-09-14). It is a service EXTENSION of the SALES service. The estate had already ruled that Migration delivers Glover's capabilities INTO the existing Sales service rather than minting a service or a project for it, while a client-project row went on describing Glover as 'the first customer project the carolverse platform serves'. A record contradicting a standing ruling is the third state to watch for: it agrees with neither, and readers believe whichever they find first. The row is CORRECTED IN PLACE and retained, never deleted — it is why Glover appears in the project history at all, and the superseded wording is kept inside the correction so the trail survives. Glover's use as the jail pilot stays true as history: that is what Glover was used to PROVE, not what Glover WAS.

Sales strategy versions are registry records that say why the strategy evolved

Ruled 2026-09-16 by ninad -- in force

The sales strategy has VERSIONS: it evolves as the business gets traction and the platform evolves, and the versions are registry records (table sales_strategy_versions, one door shared machinery). A version holds every strategy setting as a typed column, the period it was in force and the version it superseded; exactly one version per project is active. Every version after the first says why the strategy evolved - an evolution driver (business traction, platform evolution, market learning or administrator decision; RDM sales_strategy_evolution_driver), a change summary, a rationale, and evidence references for the three evidence-led drivers. A version is never edited in place; a change is a new version. The Sales Strategy store keeps no strategy of its own.

The sales strategy is owned and decided by the Head of Sales, and is defined through the operator CLI

Ruled 2026-09-17 by ninad -- in force

The sales strategy is OWNED BY THE SALES LEAD - Aurora, Head of Sales - and she is the recorded decider of every strategy version. The strategy is DEFINED THROUGH THE OPERATOR CLI: Ninad's direction reaches Aurora from his CLI session, and the version she records says the direction came from him. Carol's chat is NOT a door for defining the strategy. Ninad's words: 'carol sales strategy currently requires me to provide strategy via carol.. that is not the right design.. strategy needs to be defined via cli, and should be owned by the sales lead.' Asked who decides a new version once Aurora owns it, he chose: Aurora decides; his direction reaches her through the CLI and the record says it came from him. Unchanged: versions are registry records that say why the strategy evolved (ruling 20); a version is never edited, so version 1 keeps reading as the administrator's decision it was; Carol's other Sales Strategy operations in her internal chat are untouched; apps stay transparency surfaces (cookbook 1710).

📖System Services

One dominion per machine

Ruled 2026-09-14 by ninad -- superseded 2026-09-14

A DOMINION CAN NEVER SHARE A VM WITH ANOTHER DOMINION (Ninad, CLI-416). A dominion is a separate installation in the ordinary sense — its own machine, its own records, its own money and its own agents — so two dominions on one host would put two estates inside one blast radius, one set of OS identities and one budget meter. The rule refuses at the WRITE: the dominion register holds the host as a unique value, so a second dominion claiming an occupied machine is rejected rather than recorded and then asserted in prose nobody executes.

Ended because: Ninad ruled every project gets its own VM, so a dominion spans a bunch of machines rather than one; the no-sharing rule survives unchanged

Every project gets its own machine; a dominion spans many

Ruled 2026-09-14 by ninad -- in force

EVERY PROJECT GETS ITS OWN MACHINE, AND A DOMINION SPANS A BUNCH OF THEM (Ninad, CLI-416, 2026-09-14). A project used to be isolated by a jailed OS identity and workspace on the dominion's shared host — the kernel was the boundary, the machine was not. The machine is now the boundary: individual projects ALWAYS get a separate VM. So a dominion is not one box. The host recorded on a dominion is its BASE project's machine; every further project adds one, and the dominion's real footprint is derived from its projects rather than stored, so the two can never disagree. What survives unchanged from 'one dominion per machine' is the part that always mattered: NO MACHINE IS EVER SHARED — not between two dominions, and not between two projects. Both are enforced at the write, and a host already held by anything else is refused by name. A merely REQUESTED project is not owed a machine; approved and active ones are.

One dominion per machine

Ruled 2026-10-01 by ninad -- retired 2026-10-01

A DOMINION CAN NEVER SHARE A VM WITH ANOTHER DOMINION (Ninad, CLI-416). A dominion is a separate installation in the ordinary sense — its own machine, its own records, its own money and its own agents — so two dominions on one host would put two estates inside one blast radius, one set of OS identities and one budget meter. The rule refuses at the WRITE: the dominion register holds the host as a unique value, so a second dominion claiming an occupied machine is rejected rather than recorded and then asserted in prose nobody executes.

Ended because: Recorded by mistake 2026-10-01 17:40 (CLI-638 ran the one-off shared machinery expecting a --help): this is the wording that ruling #10 (CLI-416, 2026-09-14) already superseded as #6 -- a dominion spans many machines; no machine is ever shared. Retired in place; #10 governs. (by ninad)