Carolopedia

A public encyclopedia of Carolverse.

๐Ÿ“– Carolopedia โ€บ Guides โ€บ Reference dataGuide page

Reference data

๐Ÿ“–Agent deployment status

Whether an agent holds a post. NOT the same question as agents.status (active / retired), which answers whether the agent still exists: a benched agent is active, it simply holds no post yet. Service: Agent and Human Resources. Kept by Athena.

- bench: Created and not yet deployed to a post. While here the agent reports to the head of Agent Resources.
- deployed: Holds the post prescribed for it and reports to the line prescribed for it.

Allowed moves: bench to deployed, deployed to bench.

๐Ÿ“–Agent onboarding mandatory detail

The details a request for a new agent must carry before an agent is created from it. The onboarding door reads this record live: adding a detail is a change here, never a change to code. Service: Agent and Human Resources. Kept by Athena.

- name: The agent's name; no two agents share one.
- purpose: What the agent is for.
- project: The project the agent is deployed to.
- reports_to: The agent it reports to once deployed.
- department: Its department, housed in a realm so the agent has an address.
- level (retired): Its level in the organisation.
- service: The service it belongs to.
- subscription: The provider and model it runs on, prescribed by the requester.

๐Ÿ“–Agent onboarding permitted asker

The agents Athena accepts a request for a new agent from. The onboarding door reads this record live and the registry refuses any other asker at the write seam. Values are agent ids. Service: Agent and Human Resources. Kept by Athena.

- agt_034: Leo (Head of Strategy) may ask Athena for a new agent.
- agt_023: Orion (Deputy Chairman) may ask Athena for a new agent.

๐Ÿ“–Agent onboarding request status

Where a request for a new agent stands on its one route. Service: Agent and Human Resources. Kept by Athena.

- requested: Complete; waiting for the administrator's decision.
- refused: Incomplete or invalid when it was made; the faults are named on the request. No agent can come of it.
- approved: The administrator approved it; the agent's id is reserved.
- declined: The administrator declined it, with the reason.
- created: The agent exists, on the bench.
- build_filed: The rest of the agent's build is filed for the asker.
- deployed: The asker accepted; the agent holds its post.

Allowed moves: approved to created, build_filed to deployed, created to build_filed, requested to approved, requested to declined.

๐Ÿ“–App access policy (agents)

Which agents may read an app. One of the two audiences ruled by; the human audience is app.access_policy_humans. The gate fails CLOSED, so a value outside this vocabulary refuses every agent except the owner. Service: System Services. Kept by Radagast.

- public: Every agent without restriction โ€” the widest agent class.
- global: Every agent may read the app.
- default
- classified: Every agent may enter but sees ONLY ITS OWN data; the app scopes every row to the requesting identity.
- limited: Named agents only โ€” the explicit mapping on the app record (named_agents) IS the naming.
- confidential: The owner agent and the operator only; every other agent is refused.

๐Ÿ“–App access policy (humans)

Which humans may open an app. One of the two audiences ruled by; the agent audience is app.access_policy. The gate fails CLOSED through the subscription chain. Service: System Services. Kept by Radagast.

- public: All humans โ€” no login required.
- global: Any signed-in user, irrespective of subscription.
- default: Signed-in users whose PROJECT subscribes to the service this app belongs to.
- classified: Signed-in subscribed users, each seeing only their own data; the app scopes every row to the requesting identity.
- limited: Signed-in subscribed users NAMED on the app record (named_users) only.
- confidential: Project admin plus the carolverse admin only.

๐Ÿ“–App status

The lifecycle state of one APP โ€” a surface somebody opens. NOT the status of the service the app belongs to: a service is a business capability with money and tracks behind it, and a LIVE service can hold a DECOMMISSIONED app. That is exactly what happened when the Communications app folded into User Engagement while the Communications service carried on unchanged. Two of these values are OBSERVED (active, inactive: is anyone using it) and two are DECIDED (paused, decommissioned: do we want it running). The automated restart refuses only the decided pair. Service: System Services. Kept by Radagast.

- active: In regular use. The caretaker revives it if it falls over.
- inactive: Nobody has used it for a long time. This is an OBSERVATION, not a decision โ€” and deliberately not a kill switch: a rarely-used but needed app (an emergency tool, a yearly report) is still revived if it falls over. Gating the restart on 'active' alone would let such an app die quietly and stay dead until somebody needed it.
- paused: Deliberately stopped for now, and expected back. The caretaker does not revive it and a restart request is refused by name. Reviving it is a decision somebody makes, not something that just happens.
- decommissioned: Deliberately retired โ€” no longer needed. The caretaker never revives it, its route is not rendered, and the record STAYS so the estate can still say what the app was called, which port it held and which user it ran as. Retire, never delete: deleting the record is what once left a retired app's process running with nothing able to stop it.

Allowed moves: active to decommissioned, active to inactive, active to paused, decommissioned to active, inactive to active, inactive to decommissioned, inactive to paused, paused to active, paused to decommissioned.

๐Ÿ“–Arc status

What state a whole arc of work is in. Service: Build Initiatives. Kept by Orion.

- planned: Filed and not started: no member initiative has been worked yet.
- active: Being built: at least one member is executing, or work has begun and is unfinished.
- paused: Deliberately stopped by a decision, and expected to resume. Not a failure.
- completed: Every member has reached a terminal state and the arc's goal is met.
- abandoned: Stopped for good. Kept as history, never deleted.

Allowed moves: active to abandoned, active to completed, active to paused, completed to active, paused to abandoned, paused to active, planned to abandoned, planned to active, planned to paused.

๐Ÿ“–Audit finding closure reason

Why a Themis audit finding was closed. A closure made before reasons were recorded has none and reads 'reason unknown' - never backfilled. Service: Audit & Compliance. Kept by Themis.

- fixed_on_rescan: The same check re-ran on the same artifact and found it clean.
- rebuttal_accepted: Themis dismissed the finding on the owner's written rebuttal.
- artifact_retired: The artifact the finding is about no longer exists.
- clean_scan_record: Not a finding: a dated record, born closed, that a scan ran clean.
- waived: A recorded architecture waiver now covers the finding; it is not fixed.
- check_retired: The check that raised the finding was retired in place; the rule it enforced lives on in the one checker, which raises its own finding when the violation still stands.

๐Ÿ“–Competency grade

The grade a competency holds on a day, judged from real attempts. Service: Agent and Human Resources. Kept by Athena.

- fluent: Does this reliably and often: enough counted attempts in the window and nearly all of them succeeded.
- proficient: Does this reliably: several counted attempts in the window and most of them succeeded.
- learning: Has attempted this, and is not yet reliable at it.
- forgotten: Could do this once, and no longer can: it can no longer run, or its most recent counted attempts all failed after an earlier success.
- ungraded: No counted attempt is on record yet. An unmeasured competency is never called learning.

๐Ÿ“–Contract cost basis

The contract cost basis, a governed vocabulary of the contract register. Service: Cost Center. Kept by Marco.

- per_hour: The amount is paid for each hour worked, up to the contract's hours cap a day.
- per_day: The amount is paid for each day worked.
- per_month: The amount is paid for each calendar month of the term.
- fixed: The amount is paid once for the whole contract.

๐Ÿ“–Contract kind

The contract kind, a governed vocabulary of the contract register. Service: Cost Center. Kept by Marco.

- internship: An internship with the company for a fixed term, ending with a certificate.
- contractor: An independent contractor's agreement: services for a fee, own taxes, no employment.
- employment: An employment contract.
- vendor: A contract with a vendor the company buys from.
- service: A contract for a service the company provides to a client.

๐Ÿ“–Contract party kind

The contract party kind, a governed vocabulary of the contract register. Service: Cost Center. Kept by Marco.

- person: A person on the registry's persons record (party_ref = the person's id).
- operator: An operator on root's operator list (party_ref = the operator's login).
- vendor: A vendor on Marco's subscription register (party_ref = the subscription key).

๐Ÿ“–Contract status

The contract status, a governed vocabulary of the contract register. Service: Cost Center. Kept by Marco.

- draft: Being prepared; not sent to the party.
- sent: Sent to the party for signature.
- signed: Signed by both parties; not yet started.
- active: In force: the term has started.
- ended: The term ended as agreed.
- terminated: Ended before its term, or withdrawn before signature.

Allowed moves: active to ended, active to terminated, draft to sent, draft to signed, draft to terminated, sent to draft, sent to signed, sent to terminated, signed to active, signed to terminated.

๐Ÿ“–Contract notice kind

The contract notice kind, a governed vocabulary of the contract register. Service: Cost Center. Kept by Marco.

- end_ahead: The end watch raised the contract's end ahead of time.
- certificate_due: The end watch raised that an internship's certificate is due at its end.

๐Ÿ“–Contract template kind

The contract template kind, a governed vocabulary of the contract register. Service: Cost Center. Kept by Marco.

- internship: Template for an internship agreement.
- contractor: Template for an independent contractor agreement.
- employment: Template for an employment contract.
- vendor: Template for a vendor contract.
- service: Template for a service contract with a client.
- internship_certificate: Template for the certificate an internship ends with.

๐Ÿ“–Contract template lawyer review

The contract template lawyer review, a governed vocabulary of the contract register. Service: Cost Center. Kept by Marco.

- not_reviewed: Not for use: no qualified lawyer in its country has reviewed it.
- reviewed: Reviewed by a qualified lawyer in its country; may be used.
- superseded: Replaced by a later version of the template.

๐Ÿ“–CRM application status

Status of an outreach thread. The two values the Glover source used, plus the two lifecycle ends a thread can reach. Service: Sales. Kept by Aurora.

- sent: Outreach sent, no reply yet
- follow-up drafted: A follow-up is drafted, not yet sent
- replied: The lead answered
- closed: Thread closed โ€” outcome in notes

๐Ÿ“–CRM contact stage

Where a person at a lead stands. A customer is a contact at the customer stage โ€” one home for people in the CRM. Service: Sales. Kept by Aurora.

- contact: A person at a lead, not yet a customer
- customer: A key contact at a lead who is a customer

๐Ÿ“–CRM engagement status

Status of an active conversation with a lead (written by Carol's log_engagement). Service: Sales. Kept by Aurora.

- active: Conversation live
- paused: Parked by either side
- closed: Conversation ended โ€” outcome in notes

๐Ÿ“–CRM pipeline

Which CRM deployment a record belongs to. One deployment per pipeline of the shared CRM codebase. Service: Sales. Kept by Aurora.

- sales: Sales pipeline โ€” customers, owned by Aurora, worked by Carol
- partnerships: Partnerships pipeline โ€” research institutes, owned by Aurora, worked by Carol
- investments: Investments pipeline โ€” investors and funding, Clara's Finance track
- research: Research directory โ€” institutes and sources, owned by Obi-Wan

๐Ÿ“–CRM record status

Whether a lead or contact is live. Records retire, never delete. Service: Sales. Kept by Aurora.

- active: Live record
- retired: Retired in place โ€” kept for history, not worked

๐Ÿ“–Email grant purposes

What a person's grant of read-only access to their own mailbox is FOR. Each purpose is its own grant and its own token in the person's folder, so a token granted for one purpose is never read for another. Service: Communications. Kept by Carol.

- enrichment
- receipts: The company's subscription receipts and credit purchases are read once a day from the administrator's work mailbox for its accounts (Rulings Repo cost-center #279).

๐Ÿ“–Fundraising comparable metric

What a comparable company's multiple is a multiple of. Service: Leadership. Kept by Clara.

- arr_multiple: Valuation as a multiple of annual recurring revenue; the one the plan can apply, since it plans ARR.
- post_money_cap: A SAFE's post-money cap in euro; shown beside the valuation, never applied as a multiple.

๐Ÿ“–Fundraising comparable stage

The stage a comparable company was at when its multiple was observed. Service: Leadership. Kept by Clara.

- pre_seed: Before a priced round: friends, angels, a first SAFE.
- seed: The seed round: the first institutional money.
- series_a: Series A: the first priced growth round.
- series_b: Series B: scaling after the model is shown to repeat.
- series_c_plus: Series C and later: growth rounds beyond B.

๐Ÿ“–Fundraising instrument

Fundraising instrument Service: Leadership. Kept by Clara.

- equity: Priced equity: shares sold at an agreed valuation.
- safe: SAFE: money now, shares later at the next priced round.
- convertible_note: A loan that converts into shares at a later round.
- grant: Non-dilutive money, typically public funding; buys no shares.
- debt: Borrowing repaid in cash; buys no shares.

๐Ÿ“–Fundraising regulation

The German and EU rules whose cost the fundraising plan carries. Service: Leadership. Kept by Clara.

- eu_ai_act: EU AI Act: the European rules for AI systems - risk management, transparency, human oversight and documentation for systems that act.
- gdpr_bdsg: GDPR and the German Federal Data Protection Act (BDSG): how personal data is processed, agreed with clients and protected.
- nis2: NIS2: the EU cyber-security directive as enacted in Germany - security controls, registration and incident reporting for covered providers.
- iso_27001: ISO 27001: the information-security certification clients ask for before letting a provider into their systems.
- statutory_audit: The German statutory audit of the annual accounts (HGB), required once a company is medium-sized.
- business_insurance: Directors' and officers', cyber and professional liability insurance.

๐Ÿ“–Fundraising round status

Fundraising round status Service: Leadership. Kept by Clara.

- planned: Decided in shape but not yet open to investors.
- open: Being raised right now; investors can commit.
- closed: Finished โ€” the money is in and the round is done.
- withdrawn: Abandoned before closing; kept as history, never deleted.

๐Ÿ“–Fundraising spend category

Fundraising spend category Service: Leadership. Kept by Clara.

- engineering: Building the product: the people and the work that make it.
- infrastructure: Running it: machines, storage, networking and the model usage the estate consumes.
- sales_and_marketing: Winning customers: the sales effort, the marketing and the material behind it.
- customer_success: Keeping customers: onboarding them and making them succeed once they are here.
- research: Finding what is next, before it is a product.
- operations: Keeping the company running: finance, legal, compliance and administration.
- reserve: Deliberately unallocated, held back against the plan being wrong.

๐Ÿ“–Fundraising spend group

The three broad groups a year's planned spend is split into on the Fundraising app. Service: Leadership. Kept by Clara.

- employees: The people: salaries and what employing them costs - the dedicated client engineers, sales, customer success, core engineering and the founders.
- tokens_and_infra: Running the estate: model usage (tokens) and the machines, storage, networking and backups every client and the platform run on.
- other: Everything else: legal and fundraising costs, accounting, offices, travel, recruiting fees, insurance and marketing programmes.
- regulation_and_compliance: Regulation and compliance: what German and EU rules cost to meet - the AI Act, data protection, NIS2, ISO 27001, the statutory audit and business insurance. Its amount is the sum of the itemised compliance record, never a share typed beside it.

๐Ÿ“–Initiative initiation kind

Whether a person asked for this work or an agent raised it on its own. Service: Build Initiatives. Kept by Orion.

- agent-initiated: An agent raised this work itself, with no person asking. Autonomous.
- user-initiated: A person asked for this work. The origin names the person and the door they came through.

๐Ÿ“–Initiative origin channel

The door the initiating request came through. Recorded for user-initiated work; agent-initiated work carries the machine channel it was raised on. Service: Build Initiatives. Kept by Orion.

- email: A message that arrived by email.
- operator-cli: The operator's command line on his own machine.
- operator-vscode: The operator's code editor window.
- service-operator-door: A service operator's own door: an act she asked for inside her assignments, the person proved by the kernel at Elrond's Service Operator Performer.
- unknown: The door declared no channel, or one nobody has classified. Named rather than guessed into the nearest-looking value.
- web-chat: An agent's web chat window.
- whatsapp: Carol on WhatsApp.

๐Ÿ“–Investor kind

Who is investing: a firm or fund, or an individual on their own account. Never a user or an operator (leadership #235). Service: Leadership. Kept by Clara.

- organisation: A firm or fund investing; the person who speaks for it is its contact.
- person: An individual investing on their own account.

๐Ÿ“–Investor status

Where an investor stands in the investor onboarding pass (onboard-new-investor). Service: Leadership. Kept by Clara.

- lead: Introduced and recorded as an investor; nothing that is not public is shared (pass 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, answered in writing (phase C).
- committed: Terms agreed and the investment 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.
- withdrawn: They left after investing; the record is kept.

Allowed moves: admitted to declined, admitted to in_diligence, committed to declined, committed to invested, in_diligence to committed, in_diligence to declined, invested to withdrawn, lead to admitted, lead to declined.

๐Ÿ“–Investor access scope

What an investor may be granted. By ruling, one thing only. Service: Leadership. Kept by Clara.

- data_room_read: Named, read-only access to the Data Room and nothing else in the estate.

๐Ÿ“–Investor admission decision

The administrator's decision on an investor (pass step B1). Service: Leadership. Kept by Clara.

- admitted: Admitted: the Data Room may be opened to them read-only.
- declined: Declined: nothing beyond what is public is shared; the record is kept.

๐Ÿ“–Investor commitment status

Where money committed by an investor stands (pass phase D). Service: Leadership. Kept by Clara.

- agreed: Terms agreed: the round, the amount and the instrument.
- signed: The investment documents are signed by both sides.
- received: The money arrived against its round.
- cancelled: The commitment did not go ahead; the record is kept.

Allowed moves: agreed to cancelled, agreed to signed, signed to cancelled, signed to received.

๐Ÿ“–Investor update kind

What an update sent to an investor is (pass steps E2, E3). Service: Leadership. Kept by Clara.

- monthly_update: How the company did against its plan that month.
- weekly_showcase: The interesting things that happened in the company that week.

๐Ÿ“–Loop stage (ARR)

The ARR methodology step a loop is in: Analysis, Reach out, Respond back. Service: Communications. Kept by Carol.

- analysis: A โ€” Analysis: the ask is understood, the target resolved, the loop-vs-topic decisions made.
- reach_out: R โ€” Reach out: the question travels to the target.
- respond_back: R โ€” Respond back: the target's answer comes and is carried back to the asker.

Allowed moves: analysis to reach_out, reach_out to respond_back.

๐Ÿ“–Loop status

The lifecycle state of one ARR loop: running, completed, or ended without completing. Service: Communications. Kept by Carol.

- active: The loop is running; its stage says where it is now.
- closed: The loop completed. A full loop closes at respond_back; a one-way notice closes at reach_out.
- aborted: The loop ended without completing โ€” expired, undeliverable, voided or settled early; stage shows where it died and closed_note says why.

Allowed moves: active to aborted, active to closed.

๐Ÿ“–Onboarding role

Who performs a step in an onboarding pass. A role, never a person, so a pass outlives the individuals in it. Service: Security. Kept by Heimdall.

- receiving agent: The agent the owning agent hands a step to; it performs the step with its own machinery. The step names the agent (Elrond, Hagrid, Clara, Athena, Heimdall in project onboarding).
- orion: The operator's CLI agent. Does the estate-side work of a pass: records, verification, drafting.
- admin operator: The one human holding the authority ladder โ€” appointing, stopping, and root. Steps reserved to this role cannot be delegated.
- current operator: Any already-onboarded operator performing an ordinary step. May be the admin operator.
- new operator: The person being onboarded as an operator.
- new investor: The person, or the person speaking for a firm, being onboarded as an investor in the company behind Carolverse. Neither a new user nor a new operator: an investor is not served by the estate and does not work for it.
- new user: The person being onboarded as a user of the estate.
- owning agent: The agent whose machinery performs the step โ€” Athena for agents, Jarvis for users, Leo for projects.
- requesting agent: The agent permitted to ASK for an onboarding, which is not the same as the agent that performs it.

๐Ÿ“–Operator compliance rule

The rules an operator's Orion instance is checked against for the Operator Instance Log's compliance (CAROL-ARC-0036); each value is one check in shared machinery. Service: Communications. Kept by Orion.

- own-sign-in: Own sign-in per session -- every live Orion session rides its own recorded sign-in and no sign-in carries two (security #271, #274)
- hourly-update: Hourly update -- every completed hour worked in the last 24 hours has its update (communications #210)
- communications-read: Messages read first -- no operator communication was left unread while a later session ran (communications #203)
- workstation-gates
- no-other-way-in: No other way in -- nothing but the operator's own sign-in can admit their Orion instance: its login is on no entry list, in no sign-in block and holds no key, and every login sshd admits is root, core, an operator's own or a forced-command job (security #285, #287)
- entry-gate: Root's entry gate -- the instance's latest session reported every copy of the Orion entry gate in step with root's copy (security #286, #287)

๐Ÿ“–Operator compliance state

Whether an operator's Orion instance kept every rule CAROL-ARC-0036 carries, derived per operator by shared machinery; the Operator Instance Log's box reads it. Service: Communications. Kept by Orion.

- breach: Non-compliant -- at least one check found a rule broken; the box turns red and names each finding
- not_proven: Not proven -- at least one check could not run or its record does not exist yet; proves nothing either way
- compliant: Compliant -- every check ran and found every rule kept

๐Ÿ“–Operator rung

Service: Security. Kept by Heimdall.

- root: All access. The root login; applies definitions to the machine.
- core: The core and nothing else: everything an operator cannot change. The core login. Mutually exclusive with operator.
- admin (retired): The whole estate except the core. The operators' own logins, equal in rights. Never an operating-system group of that name: the stock rules give such a group root.
- operator: The whole estate except the core. A human working through an Orion session signed in as their own login; operators are equal in rights. Mutually exclusive with core.
- service_admin (retired): One named service's access and nothing else; its reach lies inside an admin's.
- service_operator: One named service's access and nothing else, through an Orion session; its reach lies inside an operator's.

๐Ÿ“–Person access level

The access level a person holds, and the folder tier their conversation lives under. Present on the record since the beginning and never governed; measured 2026-09-10, only two values have ever been used. Service: Communications. Kept by Carol.

- admin: The Carolverse administrator. One person holds this.
- guest: Everyone else. The default a person is born with.

Allowed moves: admin to guest, guest to admin.

๐Ÿ“–Person kind

What kind of person this is: someone who operates Carolverse agents, or someone the estate's agents serve. Ruled onto the record by and enforced ever since by a hand-written tuple inside the identity module โ€” a governed vocabulary living in a private check, which is exactly what forbids. One person may hold both hats; this records which one the person record itself is about. Service: Communications. Kept by Carol.

- employee: A human who operates Carolverse agents through chat.
- external: Someone the estate's agents serve โ€” Carol's and Leo's own users. Never gains agent operations.

Allowed moves: employee to external, external to employee.

๐Ÿ“–Person status

The lifecycle state of one PERSON in the estate. Two values are OBSERVED (active, inactive: is this person still corresponding) and two are DECIDED (decommissioned, blocked: a deliberate act by the operator). Same shape as app.status: observation must never be mistaken for a decision, because only a decision may be reversed by a decision. NOT the same question as 'verified' (has this person confirmed who they are) or 'is_test' (is this a real person at all) โ€” those are separate facts with their own homes. Service: Communications. Kept by Carol.

- active: Corresponding now, or recently enough that we would expect a reply. OBSERVED.
- inactive: Has not corresponded for a long time. This is an OBSERVATION, not a decision and not a judgement: the person keeps every right and every record they had, and a single message moves them back to active on its own. Deliberately not a way to stop talking to somebody โ€” that is what decommissioned and blocked are for.
- decommissioned: Deliberately retired โ€” this person is no longer someone the estate corresponds with, and nothing proactive reaches them. The RECORD STAYS: it is what still knows their history, their folder and what was said. Retire, never delete.
- blocked: Deliberately barred. Nothing reaches them and nothing they send is acted on. Distinct from decommissioned, which is a tidy-up rather than a refusal โ€” collapsing the two would erase why the door was shut.

Allowed moves: active to blocked, active to decommissioned, active to inactive, blocked to active, blocked to decommissioned, decommissioned to active, decommissioned to blocked, inactive to active, inactive to blocked, inactive to decommissioned.

๐Ÿ“–Person verification type

How a person is verified, from which facts stand self-confirmed. NULL means not verified. Every state requires the admin's recorded approval. Service: Communications. Kept by Carol.

- phone_verified: Name and phone are on record and self-backed; reachable on WhatsApp.
- email_verified: Name and email are on record and self-backed; reachable by email.
- verified: Name, phone and email are all on record and self-backed; reachable on both channels, defaulting to the channel a loop was triggered from.

Allowed moves: email_verified to verified, phone_verified to verified.

๐Ÿ“–Person fact source

Where a recorded detail about a person came from. Provenance is what keeps a second-hand detail from being mistaken for a first-hand one, and it decides precedence: self outranks referral, and a referral may never state verification. Service: Communications. Kept by Carol.

- self: The person stated it about themselves โ€” first-hand.
- referral: A verified person stated it about someone they referred โ€” second-hand. Never proof of identity.
- admin: The operator stated it.

๐Ÿ“–Arc phase status

What state one phase of an arc is in. Service: Build Initiatives. Kept by Orion.

- planned: Filed and not started: no member initiative has been worked yet.
- active: Being built: work on this phase has begun and is unfinished.
- paused: Deliberately stopped by a decision, and expected to resume.
- completed: Every member of this phase has reached a terminal state.
- abandoned: Stopped for good. Kept as history, never deleted.

Allowed moves: active to abandoned, active to completed, active to paused, paused to abandoned, paused to active, planned to abandoned, planned to active, planned to paused.

๐Ÿ“–Pipeline lane band state

What one lane of the build pipeline was doing at a moment of the day, as drawn in the band under the Pipeline app's day chart. Service: Build Initiatives. Kept by Orion.

- running: this lane's own work was in flight
- stalled: the master switch was on and nothing was moving on this lane
- idle: nothing was in flight on a lane the master switch does not govern (the Orion bypass)
- paused: the master switch was paused
- off: the master switch was off
- no_record: no master switch record covers this time
- future: this part of today has not happened yet

๐Ÿ“–Project status

Lifecycle status of a project in the registry. Ruled by Ninad 2026-09-06; enforced at the write seam. Service: Governance. Kept by Clara.

- requested: A user requested the project; nothing approved yet. Every new registration is born requested.
- approved: The request was approved.
- active: The project is active.
- retired: The project is no longer active. Only an operator decision moves a project out of it.

Allowed moves: active to retired, approved to active, approved to retired, requested to approved, requested to retired, retired to active.

๐Ÿ“–Project agent instance status

Where one of a PROJECT'S OWN agents stands, from Blueprint's proposal to the agent Athena creates. Distinct from agents.status: an instance is a project's claim on a role, which exists before any agent does. Service: Agent and Human Resources. Kept by Athena.

- proposed: Derived at Blueprint from Carolverse's templates against the project's stated needs; nothing is enabled or created yet.
- unauthored: Created by enabling a clone-archetype track: the role exists for the project, its substance is not yet written.
- requested: Asked of Athena through the agent onboarding route.
- created: Athena has created the agent this instance names.
- retired: No longer part of the project; kept, never deleted.

Allowed moves: proposed to unauthored.

๐Ÿ“–Project invoice status

Lifecycle of a project invoice issued at actual cost. Service: Cost Center. Kept by Midas.

- draft: Composed but not yet issued; lines may still change.
- issued: Issued for a closed period; lines and totals are frozen.
- sent: Emailed to the project's admins with a recorded mail receipt.
- paid: Payment recorded against the invoice, with its reference.
- void: Withdrawn with a recorded reason; a new invoice may be issued for the period.

Allowed moves: draft to issued, draft to void, issued to paid, issued to sent, issued to void, sent to paid, sent to void.

๐Ÿ“–Project service necessity

Whether a service in a project's business plan is one the project cannot run without, or one it may take up. Shown to the user as two separate lists. Service: Blueprint. Kept by Leo.

- mandatory: The project cannot do its business without this service.
- optional: Useful to the project, and the user may decline it.

๐Ÿ“–Pursuit status

What state a pursuit - an outcome reached through a sequence of initiatives - is in. Service: Build Initiatives. Kept by Orion.

- planned: Recorded and not started: no step of the sequence has been worked yet.
- active: Being pursued: work on its sequence has begun and the outcome is not yet reached.
- paused: Deliberately stopped by a decision, and expected to resume. Not a failure.
- achieved: Every step is closed and every success criterion is met with its proof.
- abandoned: Stopped for good. Kept as history, never deleted.

Allowed moves: active to abandoned, active to achieved, active to paused, paused to abandoned, paused to active, planned to abandoned, planned to active, planned to paused.

๐Ÿ“–Pursuit step stage

Whether a pursuit step is part of the pursuit's MVP or can happen after it. Service: Build Initiatives. Kept by Orion.

- mvp: absolutely necessary for the pursuit's outcome to be reached in the right manner
- post_mvp: can happen after the pursuit's outcome has been reached in the right manner

๐Ÿ“–Roadmap item status

Shared strategic ask and service task lifecycle Service: Governance. Kept by Clara.

- proposed: proposed
- planned: planned
- in_progress: in progress
- completed: completed
- rejected: rejected
- discontinued: discontinued

Allowed moves: completed to discontinued, in_progress to completed, in_progress to discontinued, planned to discontinued, planned to in_progress, proposed to planned, proposed to rejected.

๐Ÿ“–Roadmap service task status

Service task lifecycle: operators approve, reject and discontinue; the work makes in progress and completed Service: Governance. Kept by Clara.

- proposed: proposed
- planned: planned
- in_progress: in progress
- completed: completed
- rejected: rejected
- discontinued: discontinued

Allowed moves: completed to discontinued, in_progress to completed, in_progress to discontinued, planned to discontinued, planned to in_progress, proposed to planned, proposed to rejected.

๐Ÿ“–Sales communication model

How a sales strategy keeps in touch with customers (rule 1712, Ninad CLI-408). Service: Sales. Kept by Aurora.

- continuous: Continuous: customers keep receiving valuable engagement from declared sources, paced by cadence and stopped by suppression, never capped by count

๐Ÿ“–Sales strategy evolution driver

What moved the sales strategy to a new version. Ninad (CLI-444): the strategy evolves as the business gets traction and the platform evolves. Service: Sales. Kept by Aurora.

- initial: Initial: the first strategy a project records
- business_traction: Business traction: evidence from customers (replies, discovery, proposals, paid outcomes, or their absence) moved the strategy
- platform_evolution: Platform evolution: the platform can now do something it could not, such as a new capability, service or faster prototype, and the strategy uses it
- market_learning: Market learning: sourced research, opportunities or a change in the market moved the strategy
- administrator_decision: Administrator decision: the administrator changed direction for a stated reason that is not customer, platform or market evidence

๐Ÿ“–Sales strategy version status

Whether a sales strategy version is the one in force. Exactly one version per project is active; recording a new version supersedes it. Versions are never deleted. Service: Sales. Kept by Aurora.

- active: Active: the strategy in force; Aurora, Carol and the sales droids work to this version now
- superseded: Superseded: replaced by a later version; kept as the record of what the strategy said while it was in force

Allowed moves: active to superseded.

๐Ÿ“–Service status

Lifecycle status of a Carolverse service in the catalogue. Service: Cost Center. Kept by Midas.

- live: The record is operating: its droids run and its spend gate answers by budget.
- paused: Deliberately stopped by the switch: droids do not run and the spend gate refuses, but the record stays and can be revived. Paused and the switch move TOGETHER through the one switch door - one fact, one home.
- retired: No longer part of the operating estate. Only an operator decision revives it; a fold into another service ends in deletion with a Trash export (Ninad 2026-09-06), so 'merged' is not a status.

Allowed moves: live to paused, live to retired, paused to live, paused to retired, retired to live.

๐Ÿ“–Service roadmap item status

Status of one item on a SERVICE's roadmap (the strategic roadmap's statuses are its own set). Service: Governance. Kept by Clara.

- done: delivered; kept for the record
- in_progress: work serving this item is underway
- planned: the owner intends this; work has not started
- retired: retired in place - overtaken or withdrawn, never deleted

๐Ÿ“–Service track status

Lifecycle status of a service track. Service: Cost Center. Kept by Midas.

- live: The record is operating: its droids run and its spend gate answers by budget.
- paused: Deliberately stopped by the switch: droids do not run and the spend gate refuses, but the record stays and can be revived. Paused and the switch move TOGETHER through the one switch door - one fact, one home.
- retired: No longer part of the operating estate. Only an operator decision revives it; a fold into another service ends in deletion with a Trash export (Ninad 2026-09-06), so 'merged' is not a status.

Allowed moves: live to paused, live to retired, paused to live, paused to retired, retired to live.

๐Ÿ“–Slot sign-in kind

Whether a slot's sign-in renews or is a fixed key. Service: Cost Center. Kept by Marco.

- renewing: A plan login: an access pass that runs out and a renewal code that replaces it. Held in full by the keeper alone; callers get a copy that cannot renew.
- fixed_key: A vendor key that does not renew. Held by the keeper alone and handed by the sign-in door for one call.

๐Ÿ“–Slot state

Where a slot stands on the one path every slot enters the estate by. Service: Cost Center. Kept by Marco.

- declared: On record: its key, subscription, model, adapter and sign-in kind are named. Nothing is proven.
- enrolled: Its sign-in is installed with the sign-in keeper (made on the machine, for a renewing one).
- keeper_proven: The keeper proved the sign-in by a real call, and its renewal where it renews.
- login_proven: Every login that will use it reached it through the sign-in door.
- live: Its tracks are registered on it (cookbook 1791) and it carries work.
- suspended: Deliberately stopped by a decision and expected back. Carries no work while it stands.
- retired: Stopped for good. Kept as history, never deleted.

Allowed moves: declared to enrolled, declared to retired, declared to suspended, enrolled to declared, enrolled to keeper_proven, enrolled to retired, enrolled to suspended, keeper_proven to enrolled, keeper_proven to login_proven, keeper_proven to retired, keeper_proven to suspended, live to login_proven, live to retired, live to suspended, login_proven to keeper_proven, login_proven to live, login_proven to retired, login_proven to suspended, suspended to declared, suspended to retired.

Source: Data Management ยท Public information reflected here.