Glossary

public woven map Plectis is the public identity for everything shown on these pages and the open source slice behind them. It is the name carried by the landing page, the components and paper modules, the reader handoff surfaces, and the published repository. The system was previously called Microcosm, and that earlier name still appears in lineage notes and in technical identifiers such as package names, schema ids, and historical URLs. Authority for what the system actually is rests in the source substrate, the standards, the validators, and the dissemination gates, not in the name itself.

ScopePlectis covers the public-facing identity: the landing page, glossary, site routes, reader packets, and the canonical public source repository. A reader meets it as the name of the project across every page of this site and on the source and licence page.

ExampleThe "Source and licence" page presents Plectis as the public identity over the published, source-open repository, alongside the licence and the naming lineage from Microcosm.See it live: Source & licensesee the public identity and the open source repository it names

Not thisDo not use Plectis as proof that package ids, old URLs, or source paths were already renamed; the name is the public identity only, and the earlier Microcosm name still lives on in those technical surfaces.

Reader ruleWhen you see Plectis, read it as the public identity of the whole system and its public source slice. Where you encounter the older name Microcosm in identifiers or links, treat it as the same project under its earlier name.

Also shown asPlectis public map

Search handlesplectis source map, Latin plectere, plectere

Generated from the governed public vocabulary for Plectis.

bounded public object The system is built as a set of these units rather than one large program, and each one is presented on its own card. A component card names the unit, says what it does, gives the evidence line that backs it, links to its source route, and marks where its scope stops. Each component can be opened and inspected on its own.

ScopeComponent covers the reader-facing units that make up the system, encountered across the public site wherever a unit is named, carded, or linked, with the full set gathered on the components page.

ExampleThe Cold Reader Route Map is one component: a single unit whose job is to lay out a route through the system for someone arriving without prior context, shown on its own card with its evidence line and source route.See it live: Cold Reader Route Mapopen one live component card

Not thisA component is not a marketing feature and not the whole system in miniature. It is a single unit of running code with a stated boundary, and the public word does not mean every underlying source identifier has been renamed from organ.

Reader ruleTake a component as one bounded unit doing one job, and read its evidence line and scope limit to see what it is responsible for and where that responsibility ends.

Also shown ascomponent card, bounded public object

Search handlesorgan, public object

Generated from the governed public vocabulary for Plectis.

what evidence stops Every component, evidence class, and published packet on this site carries a scope limit. It marks the edge of what the supporting evidence covers, so that a real result stays a claim about exactly what was checked and does not stretch into launch readiness, whole-system correctness, hosted-service behaviour, professional advice, or private runtime state. A local fixture can pass while the scope limit still rules out any wider guarantee.

ScopeScope limits appear wherever a result, component card, digest row, evidence page, or agent answer separates what is shown from what is not shown. The same boundary is recorded in source identifiers as a claim ceiling or authority ceiling.

ExampleThe doctrine card "Bind authority to transaction scope" is a scope limit in action: a unit's authority is tied to the bounded transaction it ran, so its claim cannot extend past what that transaction actually covered.See it live: Bind authority to transaction scopeopen the doctrine card that ties a claim to its bounded scope

Not thisA scope limit is not a flaw, a hedge, or an admission that a result is weak. It is the precise statement of how far one verified result reaches, leaving everything outside that line unclaimed rather than quietly assumed.

Reader ruleWhen a result is shown, read its scope limit to see how far the evidence reaches. The result holds only within that boundary, and nothing beyond it is being claimed.

Also shown asscope boundary, claim boundary

Search handlesclaim ceiling, authority ceiling

Generated from the governed public vocabulary for Plectis.

type of support When a card or result on this site is marked as backed, its evidence class is the category of that backing. The classes distinguish, for example, a result whose support is a link to a source row, one whose support is a fixture that passed, one whose support is a tool that ran locally, and one whose support is a recorded review. Each class carries its own ceiling on what may be claimed from it, so two results can both be supported while resting on very different kinds of evidence.

ScopeEvidence class covers the typed backing attached to public results, cards, and packets. A reader meets it on result and component pages where a claim is shown alongside the category of support that stands behind it, and most directly on the evidence page that sets out what a pass proves.

ExampleOn the evidence page, a result marked as fixture-backed carries the fixture-pass evidence class: its support is a test fixture that ran and passed, which is a different and narrower kind of backing than a row linked directly to a source file.See it live: What the pass proves (evidence)see results sorted by the kind of support behind them

Not thisAn evidence class is not a quality score or a rank that makes one result better than another, and a high or strong-sounding class is not proof of launch readiness, security, or whole-system correctness. It names the kind of support, not a verdict.

Reader ruleCheck which evidence class a result carries, and read it as a statement about the kind of support, not the strength of every conclusion. A class sits next to a scope limit that names what that support does not establish.

Also shown asevidence kind, evidence profile

Search handlesevidence rank, proof consumer class

Generated from the governed public vocabulary for Plectis.

inspectable artifact row A record is the inspectable object a page points to when it refers to something more solid than a sentence. Each record carries what produced it and where its authority stops, and it sits below its owning source rather than replacing it. Records are how narrative pages connect to source authority: a reader can open the actual result row, receipt, ledger, or generated projection behind a statement.

ScopeThe term covers concrete source and generated artifacts across the site: result rows, receipts, generated JSON outputs, review packets, ledgers, and verification entries. A reader meets records wherever a page links out to something inspectable rather than describing it in prose.

ExampleThe doctrine card "Generated-result record source inversion" concerns exactly this: a generated record, such as a result file emitted by a tool, must stay subordinate to the source that produced it rather than being treated as the authority itself.See it live: Generated-result record source inversionopen a rule about how generated records relate to their source

Not thisA record is not a paragraph of explanatory text and not a claim that becomes true by being written down. It is a concrete artifact, row, or generated output that someone can reopen and check.

Reader ruleWhen a page points you to a record, open it and read what it actually preserves and where its scope ends. A record holds a checkable object; it does not make a claim true merely by existing.

Also shown asresult record, verification record

Search handlesreceipt, audit record, generated record

Generated from the governed public vocabulary for Plectis.

underlying working base The substrate is everything the public pages are generated from: the source files, the standards, the recorded state, the validators, and the tools that act on them. It is the concrete, inspectable layer beneath any summary, route, or evidence view. A generated page can describe or point into the substrate, but it does not own the source records, package identifiers, or state transitions that live there.

ScopeThe term covers the source layer of the whole system: files, standards, ledgers, recorded state, and tooling. A reader meets it wherever the pages distinguish the generated public view from the source it was derived from.

ExampleThe Source and license page is the entry point into this substrate, opening onto the source files and records that the rest of the site is generated from.See it live: Source & licenseopen the source layer the pages are generated from

Not thisA substrate is not a vague word for the whole project, and not a mystical layer behind it. It is the specific, inspectable set of files and records that the pages are generated from.

Reader ruleWhen something is called the substrate, treat it as the lower source layer that a page is reporting on, and look to it rather than the page when you need the actual file or record.

Also shown assource substrate, workflow substrate

Search handleslive substrate, runtime substrate

Generated from the governed public vocabulary for Plectis.

where truth is owned Every generated surface on this site, a page, a digest, an AI summary, is a projection of something lower down. The source authority is that lower thing: a source file, a standard, a validator, a ledger, or a generated sidecar with an ownership contract. When prose, HTML, or a summary may have drifted, the source authority is where the actual claim lives and where a fact is settled. A projection can route to its source authority, but summarising a fact does not make the summary the owner of it.

ScopeSource authority appears wherever a public page describes itself as a map, projection, record, or digest, and points to the underlying file, standard, validator, or ledger that holds the fact. It marks the boundary between a generated surface and the material it is drawn from.

ExampleThe vocabulary registry standard is a source authority: a glossary row on this site can cite it for the meaning of a term while the row itself remains a projection that owns nothing.See it live: Generated-result record source inversionopen the anti-pattern that fires when a generated record is mistaken for the source that owns the fact

Not thisSource authority is not a generated page, a digest, or an AI answer. Those are projections; they hold authority only when a governing standard explicitly names them as the owner of the fact.

Reader ruleWhen a page makes a claim, the source authority is the artifact it stands below; treat that artifact, not the page, as the place the fact is owned.

Also shown assource of record, governing source

Search handlessource owner, authority posture

Generated from the governed public vocabulary for Plectis.

source-level runtime unit The system is built as a set of these units rather than one large program. Each organ does one job, such as mapping a route, running a check, importing source material, or generating a page, and can be opened and inspected on its own. Each one carries its own boundary and a record of what it is allowed to assert, so a unit's reach is fixed and visible rather than implied.

ScopeThe term covers every bounded unit the system is assembled from. A reader meets it in source paths and identifiers such as organ_registry.json, and meets the same units as components throughout the public pages, where each can be opened on its own.

ExampleA concrete organ is the Source Projection Import Protocol, a unit that brings source material across into the public slice; it is listed and openable among the components.See it live: Source Projection Import Protocolbrowse the units, each openable on its own

Not thisAn organ is not a biological metaphor and not a marketing feature. It is a unit of running code with a stated boundary.

Reader ruleWhen a source path or identifier names an organ, read it as one bounded unit doing a single job; the same unit appears on the public pages as a component.

Also shown assource organ, organ id

Search handlesruntime organ, organ registry

Generated from the governed public vocabulary for Plectis.

source-linked check result When a statement on this site claims it is supported, the witness is the concrete artifact behind that support: the output of a validator, a test, or a source-row check, naming exactly what was examined and what held. It is evidence for one bounded statement, not a verdict on the whole system.

ScopeWitness covers the evidence layer of the system: the checkable records that sit behind supported claims on components, doctrine cards, and the evidence page, where the public label is check result or verification record.

ExampleOn the evidence page, the record of what a passing check examined, such as a source-row check or a validator run, is a witness: it names the command and the rows it inspected and the one claim that result supports.See it live: What the pass proves (evidence)see the records that stand behind a passing check

Not thisA witness is not legal testimony, a mathematical proof on its own, or a guarantee that the whole system is correct. It records that one named check passed.

Reader ruleRead what a witness actually checked before relying on it. It vouches for that one claim and nothing wider.

Also shown asverification record, witness

Search handlespublic witness, proof witness, witness route, witness surface

Generated from the governed public vocabulary for Plectis.

has a route Across Plectis, an object is treated as navigable when it can be opened, cross-referenced, checked, and traced back to its source instead of only being named. A navigable component, for example, links to the source file that defines it, the standards it answers to, and the check that confirms it. The opposite is a dead term: a word that sounds meaningful but offers no route to anything concrete.

ScopeThe property applies to glossary rows, components, records, and pages throughout the site, and is most visible on the architecture map, where each part connects through to the source material it stands for.

ExampleThe architecture map is a navigable surface: each area and component on it links through to the source files, standards, and checks it represents, so you can move from the overview down to the exact material behind any box.See it live: How it fits together (architecture map)follow a map whose every part routes to its source

Not thisNavigable does not mean important, prominent, or well written. A heading can look significant and still be non-navigable if it offers no anchor, owner, or source reference to follow.

Reader ruleWhen something is described as navigable, expect a real link, anchor, or command behind it, and follow that route to the source if you want to confirm the claim yourself.

Also shown asroutable, discoverable

Search handlesrouteable, navigability

Generated from the governed public vocabulary for Plectis.

close the durable loop It describes a finished pass that did the immediately useful follow-through, not one that wandered off into new scope. When a task surfaces something that would otherwise go stale or be hard for the next person to find, the extra work is to make that one result durable: name the boundary, do the smallest improvement that prevents rediscovery, run a focused check, and leave evidence. The boundary is part of the trait: the work has a source case, a place it belongs, a check, and a clear stopping point.

ScopeThe term covers how a unit of work is judged complete across the system, and it appears wherever a pass reports what it finished and what it deliberately left for later, most directly on the surfaces that audit whether a pass closed its loop honestly.

ExampleThe Agent Completion Faithfulness Audit is a concrete instance: it is the check that compares what a pass claims it finished against what it actually closed, which is the boundary that above and beyond stays inside.See it live: Agent Completion Faithfulness Auditopen the audit that checks whether a pass honestly closed its loop

Not thisAbove and beyond is not speculative scope expansion or doing more than was asked for its own sake. It is bounded follow-through that makes one result durable and then stops at a named boundary.

Reader ruleWhen a pass is described this way, take it to mean the result was made durable and was bounded, not that scope was expanded; the record of what was checked tells you how far the follow-through actually reached.

Also shown asgo above and beyond, going above and beyond

Search handlesabove-and-beyond, beyond the ask, extra mile, go further, overdeliver

Generated from the governed public vocabulary for Plectis.

actor classification axes Rather than ranking actors on one scale from weak to strong, the system measures them along several axes at once. The primary axis is substrate authority, which marks whether an actor has live, direct access to the system's own files and tools (Type A) or works from an interface, an API, an injected copy of context, or the public web without that direct access (Type B). The other axes, including capability tier, invocation surface, topology role, evidence access, purpose lane, and reasoning budget, are recorded separately so that being clever, being expensive, and being delegated never get confused with having authority over the real material.

ScopeActor axes appear wherever the system labels who or what is acting, including handoffs between a Type B service and a Type A agent, prompt and route descriptions, and the documentation for working through a coding agent.

ExampleA coding agent running with live access to the repository is an actor that sits at the Type A end of the substrate-authority axis, with a high capability tier and a delegated topology role, all distinguished at once by the axes.See it live: With a coding agentsee a Type A actor, a coding agent with live repository access, in use

Not thisActor axes are not a single ranking of actors from least to most powerful, and substrate authority is not the same as intelligence or cost. An actor can be highly capable or expensive yet still sit on the Type B side because it lacks direct access to the system's real files and tools.

Reader ruleWhen an actor is described by where it sits on these axes, read each axis on its own. A capable or costly actor is not automatically one with direct authority over the system, and a delegated helper with live access can hold more authority than a powerful service that only sees a copy.

Also shown asactor_axes, Type A/B actor axes

Search handlescon_016::actor_axes, substrate authority axes, type a type b concept

Generated from the governed public vocabulary for Plectis.

standard-owned decision handle The system organises navigation as rows, not as monolithic documents. Each affordance row is the atomic unit of that navigation surface: it states one option, the next thing an agent or reader could open, along with enough structured detail to decide whether to open it. A row can be shown at different depths, from a one-line flag through a fuller card to a detailed view with the exact command that produced its evidence, so a choice can be made from a budgeted menu instead of by searching through source files.

ScopeAffordance rows underlie the system's browse and navigation surfaces, where each artifact kind, components, paper modules, doctrine cards and others, is listed as rows at varying depths. They appear wherever the public pages or internal tools present a menu of things to open rather than a raw file listing.

ExampleThe Navigation Hologram Route Plane is the component that emits the system's artifacts as these rows and projects them as a navigable menu, so it is a working instance of affordance rows in use.See it live: Navigation Hologram Route Planeopen the component that turns artifacts into navigable rows

Not thisAn affordance row is not a row in a spreadsheet or database table, and not a styling choice for laying text out in lines. It is a structured navigation entry that bundles one option's identity, cost, evidence, edges, and state.

Reader ruleWhen you meet an affordance row, read it as one option on a menu: it tells you what the thing is, what opening it costs, and what backs it, so you can decide your next read without scanning the underlying files.

Also shown ascognitive asset row, standard-owned affordance row

Search handlesnavigation row, option row, choice row

Generated from the governed public vocabulary for Plectis.

agent authored durable synthesis When a coding agent working inside this system learns something worth keeping, such as a pattern it noticed or a correction it made, it deposits that into an agent seed rather than into the operator's raw seed. The deposit is stamped with the agent that wrote it and the sources it drew on. It is treated as useful but lower authority than the operator's own statements of intent, so the system can retain what an agent learned without that material being mistaken for the operator's voice.

ScopeAgent seed names the attributed AI-authored layer of the system's substrate, sitting alongside the operator-voice raw seed. A reader meets it on the pages about agent reliability and about how agent observations feed back into the system's doctrine.

ExampleThe Voice To Doctrine Self Improvement Loop is the component that carries agent-authored seed material onward, taking what an agent recorded and folding it into the system's standing doctrine while preserving who wrote it.See it live: Voice To Doctrine Self Improvement Loopsee where agent-authored seed material feeds back into doctrine

Not thisAn agent seed is not the operator's own voice and not source authority on intent. It is also not the agent's private working memory: it is durable, attributed material meant to be kept, distinct from the raw seed that records the operator directly.

Reader ruleTake an agent seed as an AI agent's recorded reasoning, attributed to that agent, not as the operator's intent. It carries who wrote it and what it drew on, so weigh it accordingly.

Also shown asagent_seed, agent_seed.md, agent-authored seed

Search handlesagent voice

Generated from the governed public vocabulary for Plectis.

curated external substrate Annexes live under the annexes/ directory and hold shape-level notes about external sources: what problem each one solves and which patterns are worth borrowing. They exist so that before a piece of machinery is built from scratch, the system can check whether the same shape has already been solved elsewhere and translate the idea in, rather than re-deriving it or forking another project's structure. Each annex is a reference point for a pattern, never a binding rule the system must obey.

ScopeAnnex covers the layer of curated external references the system draws on for design patterns and prior art. A reader meets it in the import and drift-control area and wherever a component records that its shape was informed by outside work.

ExampleThe Pattern Binding Contract is a concrete instance: a component that governs how a borrowed external pattern is bound into the system's own form before it is allowed to take effect.See it live: Pattern Binding Contractopen the component that binds a borrowed pattern into local form

Not thisAn annex is not a dependency, a fork, or imported source code that the system runs. It is a pattern-level note about outside work, kept separate from the system's own authority.

Reader ruleTreat an annex as a pointer to outside prior art, not as part of the system's own authority. It tells you where a pattern came from and how it was adapted, not what the system is required to do.

Also shown asannex note, annex substrate

Search handlescurated external, adapted substrate, annex family, pattern fuel, annex prior art, annex prior-art pressure, prior art pressure field

Generated from the governed public vocabulary for Plectis.

judgment challenge lifecycle When the system makes a judgment, such as labelling a route or expecting a particular result, that judgment can be contested. The appeal lifecycle is the path that contest follows: the challenge is classified by cause, such as a model failure, a weak prompt, a lost packet, a wrong expected label, a stale projection, or a gap in the underlying scheme; it is handed to whichever plane is responsible for repair; it can hold back affected changes until it is settled; and it ends with a written rationale and, where needed, a test that proves the fix.

ScopeThe term covers governance over contested judgments across the system, including challenges raised by operator review, route judgment, and projection checks. A reader meets it wherever a label or decision can be formally disputed and tracked to resolution.

ExampleThe operator-court appeal ledger is a concrete appeal lifecycle in use: entries record judgments that operators have challenged, the classified cause, and the rationale that closes each one, fed by the Cognitive Operator Registry that holds the operator contract.See it live: Cognitive Operator Registryopen the component that records and validates operator-raised challenges

Not thisAn appeal lifecycle is not a legal court process and not a record of a row that errored and was discarded. It is the tracked path a deliberately contested judgment follows from challenge to recorded resolution.

Reader ruleRead where an appeal sits in its path before trusting the judgment it contests. A pending appeal means a judgment is under dispute and may be holding back the changes it touches; a closed one carries the rationale that settled it.

Also shown asappeal_lifecycle, operator court appeal

Search handlesappeal row, appeal review

Generated from the governed public vocabulary for Plectis.

execute verified changes Apply is the execution half of the observe-then-apply pair: observing gathers candidate changes, applying is the only step permitted to alter the system's files and records. Each apply names what it touches and what operation it performs, validates the state before and after, and where possible records how to undo it. It is the disciplined gate through which any modification to the substrate must pass.

ScopeThe term covers the mutation lane of the system, the part that writes changes rather than merely reading or proposing them. A reader meets it on the architecture map, in the component that authorises governed mutation, and in the doctrine cards that mark what an unsafe apply looks like.

ExampleThe doctrine card "Blind irreversible mutation" (AP-8) is a concrete instance: it marks an apply that changes source state without a clear target, validation, or way to undo it, which is exactly what the apply lane is built to prevent.See it live: Blind irreversible mutationsee the failure the apply lane guards against, named as a doctrine card

Not thisAn apply is not the gathering or proposing of candidate changes, and it is not any edit made freely without a stated target, validation, or rollback. Those are observations or unsafe mutations, not a governed apply.

Reader ruleWhen something says it was applied, expect a specific target, a stated operation, and a before-and-after check behind it, not an unbounded edit. Observations alone do not change anything until an apply runs.

Also shown asapply lane, apply plan, mutation

Search handlespatch

Generated from the governed public vocabulary for Plectis.

artifact class The system is not one flat list of files. Its objects are grouped into a fixed set of kinds, and each kind has its own page where every member of that class is listed together. An artifact kind names one of those classes. Choosing a kind narrows the whole system to one type of thing, for example all components or all paper modules, before you open any single entry.

ScopeArtifact kinds organise the browsable surface of the system. A reader meets them as the top-level groupings on the public pages, such as the components page, the paper modules page, and the doctrine page, each of which holds the items of one kind.

Example"Components" is an artifact kind: the class of self-contained units of working machinery, with every such unit listed together on the components page.See it live: All componentsbrowse every item of one kind on a single page

Not thisAn artifact kind is not a single file, component, or page on its own. It is the category that groups many such items, the type they share rather than any one instance.

Reader ruleWhen you meet an artifact kind, read it as the category you are inside: it tells you what type of object every row on that page is, and the boundary of what that page can contain.

Also shown asartifact_kind, kind

Search handleskind id, kind atlas kind, atlas kind, artifact class

Generated from the governed public vocabulary for Plectis.

nearly-mathematical system rule The doctrine is layered: axioms at the top, then principles, then standards and skills below them. An axiom is a formal declaration that holds across every context the system operates in, such as voice authority, projection discipline, or operator scope. A principle is derived from an axiom and judged against it in a bounded setting, whereas the axiom is the fixed point the rest of the lattice composes against. The system targets roughly seven such axioms, and they remain provisional.

ScopeAxioms appear in the doctrine and the rules-and-ideas reference, where they form the top tier of the lattice above principles, standards, and skills. There are about seven, and they govern invariants such as voice authority, projection discipline, lattice connectivity, operator scope, and primitive choice.

ExampleAX-7, "Typed partiality and refusal", is a concrete axiom: it fixes how the system represents incomplete knowledge and when it must decline rather than guess, an invariant every lower rule is built to respect.See it live: Typed partiality and refusalopen one axiom in the doctrine lattice

Not thisAn axiom is not a style preference, a goal, or a feature of the product. It is also not the same as a principle: a principle is a derived rule applied in context, whereas an axiom is the underived constraint that principle is measured against.

Reader ruleRead an axiom as the strongest, most general commitment on the page: if a lower rule appears to conflict with it, the axiom is what holds. It states an invariant, not a procedure.

Also shown asaxiom candidate, pri_axiom

Search handlesinfinity stone, system axiom, primitive constraint

Generated from the governed public vocabulary for Plectis.

one compression level packet Many records on this site are written as a ladder of bands rather than a single block of text: word, phrase, flag, card, context, deep, and evidence, depending on the profile. The same item is available at each band, and the bands sit one inside the next like a telescope or a set of nested dolls, so a short browse can open into a working summary and then into full detail. A band is governed by a contract, not by a word count, so what appears at each level is fixed by rule rather than by how much someone happened to write.

ScopeBands appear wherever the site offers a thing at more than one depth: component and paper-module summaries that expand, doctrine cards, and the layered entries in the doctrine reference. The vocabulary comes from the compression profiles and the navigation design that the public pages are generated from.

ExampleThe doctrine reference entry that presents a standard as a schema contract with an explicit scope limit is one band in action: a single fixed level of description that states exactly what it covers and what it does not.See it live: standard as schema contract with explicit scope limitopen one entry written at a single fixed band

Not thisA band is not a paragraph length or a writing style, and it is not the whole record. It is one defined level of a depth ladder, with a contract for what that level must contain.

Reader ruleA band tells you the depth of what you are reading, not just its length. If a band does not answer your question, follow it down to the next band rather than assuming the detail is absent.

Also shown ascompression band, band schema

Search handlesband ladder, russian doll band, definition band, telescope band, telescoping band, holographic tier

Generated from the governed public vocabulary for Plectis.

single-call external worker lane A bridge carries one prompt packet out to an external worker, such as a separate reasoning model or research run, and carries one response packet back. The worker sees only what the controlling lane chose to send, and the response returns as candidate evidence that the owning lane then validates, imports, or discards. The same packet can be sent to many workers in parallel, which is what makes a bridge useful for research, parallel reasoning, and large population work.

ScopeThe term covers the external worker lane and its dispatch and response machinery. A reader meets it wherever the site describes work sent to separate workers, such as parallel reasoning, research runs, or bulk population, and in the runtime component that carries this work across phases.

ExampleThe Bridge Phase Continuity Runtime is one concrete instance: the runtime unit that carries bounded bridge work across phases of a task and keeps a single dispatch-and-response round coherent over time.See it live: Bridge Phase Continuity Runtimeopen the runtime component that carries bridge work across phases

Not thisA bridge is not the system's conductor and not an autonomous agent that explores the codebase, runs many steps, or makes changes by itself. It is a one-packet-out, one-packet-back transport with all orchestration held outside it.

Reader ruleTreat anything a bridge returns as a worker's answer to a fixed packet, not as a decision the system has already acted on. The surrounding lane owns what was sent and what is done with the reply.

Also shown asbridge runtime, bridge dispatch, external worker

Search handlesbrowser bridge

Generated from the governed public vocabulary for Plectis.

stake becomes upkeep Care is what turns a stake into upkeep. An agent acting with care makes maintenance, continuity, and the comprehension of whoever comes next into visible obligations: it fixes route gaps, preserves provenance, avoids bloating adapters, and leaves explicit closeout records of what was done. It is not a decorative value word. On this system it attaches to concrete actions such as running validators, probing routes, and recording receipts, so the care can be seen in evidence rather than merely asserted.

ScopeCare covers the maintenance-and-continuity dimension of how agents act on the system: protecting the next person or agent from re-deriving lost context, inheriting stale facts, or losing the original intent. A reader meets it across the agent reliability and continuity material, and in the audits that check whether a completed task left an honest, faithful record.

ExampleThe Agent Completion Faithfulness Audit is care made concrete: it checks that a finished task left an accurate record of what was actually done, rather than a tidy claim the underlying files do not support.See it live: Agent Completion Faithfulness Auditopen the audit that checks a finished task left an honest record

Not thisCare is not sentiment, politeness, or a general value statement about doing good work. It is a specific obligation to leave upkeep behind: provenance, validation, and closeout records that the next agent can rely on.

Reader ruleWhen work here is described as done with care, look for the upkeep it left behind: a closeout record, a validator that ran, a preserved trail. Care that leaves no such trace is just a word.

Also shown assystem care, agent care

Search handlescare directive, care register, care posture, care and passion

Generated from the governed public vocabulary for Plectis.

unprimed capable agent A cold agent is a coding or reasoning agent that opens this system fresh, without the context a previous session would have carried, and without any unwritten shared knowledge to fall back on. To act safely it has to read the source, the standards, and the recorded state, and from those work out what each thing does, what opens it, what proves it, and what comes next. The system is designed so that this is possible: orientation comes from the artifacts, not from folklore held in someone's head.

ScopeThe term covers the kind of agent the documentation, standards, and entry surfaces are written for: one with no prior-session memory. A reader meets it across the entry and orientation pages, the coding-agent guide, and the Cold-Reader Route Map, wherever the system explains how a fresh agent is meant to find its way in.

ExampleThe "With a coding agent" page is a concrete instance: it walks a coding agent that has just been pointed at the system through its first moves, assuming no earlier context, which is exactly the cold-agent situation.See it live: With a coding agentsee the first moves a fresh agent is walked through

Not thisA cold agent is not a less capable or restricted agent, and not a person new to the team. It is a fully capable agent that simply begins with no session memory and must orient from the written artifacts rather than from remembered context.

Reader ruleWhen a page assumes a cold agent, it is assuming you arrive with no prior context and everything you need is on the page or one click away. Take it at face value: if something cannot be worked out from the written artifacts, that is a gap in the system, not knowledge you were expected to already have.

Also shown ascold reader, cold session

Search handlesfresh agent, cold boot, fresh capable agent

Generated from the governed public vocabulary for Plectis.

situated repair judgment In this system common sense is the live judgment that connects fixed governance to the case in front of an agent. It reads the axioms, standards, routes, and recorded state, applies ordinary intelligence to the specific situation, checks whether the names and routes it assumes actually resolve, and acts on the cheapest truthful surface available. When the work reveals a reusable gap, such as a missing route, standard, or recorded fact, the lesson is folded back into the artifact that owns it, with the originating case cited. It is the non-brittle part of the system's intelligence: source-backed and testable rather than improvised.

ScopeCommon sense covers how agents move from the system's explicit governance to a correct action on a particular task, and how they feed reusable lessons back into shared surfaces. A reader meets it across the agent reliability and continuity areas of the site, wherever judgment, repair, and lesson propagation are described.

ExampleThe area page on agent reliability and safety is a concrete home for this term: it gathers the components that govern how an agent infers a correct, source-backed action and records what it learned, which is common sense in operation.See it live: Area: agent reliability & safetysee where situated agent judgment lives on the site

Not thisCommon sense is not ungoverned instinct, intuition, or a licence to improvise outside the rules. It is judgment bound to the system's axioms, standards, and live state, and incomplete until any reusable lesson is propagated back.

Reader ruleWhen a result is described as reached by common sense, read it as a judgment derived from the system's stated rules and live state, not as a guess. It should be traceable back to the routes, facts, and standards it drew on.

Also shown ascommonsense, agent common sense

Search handlestype a common sense, common-sense up propagation, common sense up propagates

Generated from the governed public vocabulary for Plectis.

old path support When a site is renamed or reorganised, links and identifiers that people already hold would otherwise break. A compatibility route is the machinery that keeps those old paths resolving: a tombstone page, a redirect, an alias, or a manifest entry that takes the visitor to the current location. It names the old route, the new route, the behaviour, and the scope, so the move is visible rather than silent.

ScopeCovers retired Microcosm-era URLs, source paths, and identifiers that must continue resolving after the move to Plectis. A reader meets one whenever an old link or bookmark lands on a tombstone or redirect that points to the current page.

ExampleThe old Microcosm site root is a compatibility route: it shows a tombstone and forwards visitors to the current Plectis site rather than serving the former content as if it were still live.See it live: Cold Reader Route Mapopen the component that maps readers from any entry point to the current surface

Not thisA compatibility route is not evidence that the old name is still the current brand, and it is not a separate active site running in parallel. It is a one-way bridge from a retired address to the live one.

Reader ruleTreat a compatibility route as a forwarding link, not as a second live site. Where it leads is the current surface; the old address it came from is retired.

Also shown aslegacy route, tombstone route

Search handlesold route, redirect route, migration route

Generated from the governed public vocabulary for Plectis.

preserve through bands In this system compression is governed, not casual. Every compact summary is produced under a declared profile that fixes how much detail a given band carries, so a one-line entry, a card, and a full module are different rungs of the same material rather than arbitrary trims. Each row records what was preserved and what was omitted, and keeps a path back to the source it stands for, so a reader can always open the fuller layer beneath any summary.

ScopeCompression governs how the public pages, component cards, paper modules, and field-guide entries are derived from the underlying files and records. A reader meets it wherever a short summary stands in for a larger artifact and offers a way to open the fuller layer.

ExampleThe Navigation Hologram Route Plane is a concrete instance: it is the running surface that holds these banded, profile-governed views and the routes that let a reader move from a compact row down to its source.See it live: Navigation Hologram Route Planeopen the component that turns source material into banded, drillable views

Not thisCompression is not minification, lossy file shrinking, or a loose vibe summary. It is preservation through declared bands that always names its omissions and keeps a route back to the original material.

Reader ruleTreat a compressed row as a faithful but partial view: it carries an omission record and a route back to source, so when detail matters, follow that route rather than relying on the short form alone.

Also shown ascompress, summarize safely

Search handlessummarise safely, context compression, holographic compression, navigation compression, profile-governed compression, telescope compression, telescoping compression

Generated from the governed public vocabulary for Plectis.

governed compression rulebook Each profile is tied to a specific artifact kind, such as a voice record, a relational map, a peer-knowledge note, or a term definition. It names the bands the artifact can be projected into, the schema each band must follow, the evidence policy, and the validation check, so that a cheap automated worker, a larger model, and a person all shorten the same artifact into the same shape. Four profiles run today, covering voice records, relational maps, peer-knowledge notes, and vocabulary terms.

ScopeThe term covers the rulebooks that govern banded compression across the system. A reader meets it behind any surface that presents the same content at different levels of detail, and it is grounded in the navigation and route-plane machinery that projects artifacts through bands.

ExampleThe vocabulary-term profile is a concrete compression profile: it governs how a vocabulary term is projected into a word, a phrase, a flag, a card, and deeper bands, which is the same laddered shape this glossary entry follows.See it live: Navigation Hologram Route Planeopen the route plane where banded compression is projected

Not thisA compression profile is not a file-size or data-compression setting, and not a one-off summary someone writes by hand. It is a declared rulebook, bound to a specific artifact kind, stating which details a shortened form must keep and which collapses are not allowed.

Reader ruleWhen a piece of content here is shown at varying lengths, the compression profile is what fixed which details had to survive and which were allowed to fall away; read it to know what a short form is guaranteed to still carry.

Also shown asprofile, profile_id

Search handlesrussian doll profile, band profile, compression rulebook

Generated from the governed public vocabulary for Plectis.

named system object Concepts are the system's defined nouns, as distinct from its procedures. Each one fixes a single object or idea, gives it a stable identifier and a short description, links to where it is defined in the source, and connects to the mechanisms and principles that use it. Together they form the shared ontology that mechanisms act on and principles reason about, so that a recurring object keeps one settled meaning across the whole system.

ScopeConcepts cover the named objects in the doctrine layer, distinct from anti-patterns, axioms, and principles. A reader meets them wherever the doctrine refers to a defined object by name, and on the doctrine pages where those objects are listed and described.

ExampleExecutable Doctrine Grammar is one such named object: a defined idea in the system's doctrine that fixes what it means for a rule to be runnable before it is treated as authoritative, carrying a stable name other doctrine can refer to.See it live: Executable Doctrine Grammaropen one named doctrine object and read what it fixes

Not thisA concept is not a step, a procedure, or a tool you run. It is the name and definition of an object, not the action taken on it; the doing lives in mechanisms and skills.

Reader ruleTreat a concept as the settled meaning of one named object. When something else on the site refers to it, read the concept to learn exactly what that object is, not how to do anything with it.

Also shown ascon, con_*, doctrine concept

Search handlesnoun

Generated from the governed public vocabulary for Plectis.

critique becomes thinking trait Critic posture is one of the system's named judgment traits, used when people and an agent are working an idea out together. Instead of agreeing and moving on, it pauses to test the idea: it names the candidate term being introduced, checks whether the system can actually route to it, and asks what a newcomer would miss. When a criticism holds up under that test, it is not left as a passing remark; it is turned into something durable, such as a refined definition, a recorded rule, or a standard.

ScopeCritic posture covers the judgment trait applied during human and agent brainstorming, where ideas are stress-tested before they become doctrine. A reader meets it in the doctrine and agent-reliability material, and sees its results in the recorded rules and anti-patterns that stabilized criticism produces.

ExampleThe Routing Anti Patterns Registry is a concrete result of critic posture: a recorded set of failure modes, each one a criticism that held up under testing and was written down as a durable rule rather than left as a passing objection.See it live: Routing Anti Patterns Registryopen the recorded failure modes that stabilized criticism produces

Not thisCritic posture is not a separate reviewer role that must be spawned, and it is not a judgment that the whole system is flawed. It is the habit of testing one idea at its weak points and recording what holds.

Reader ruleWhen you meet critic posture on this site, read it as the discipline of pressing on an idea's weak points and then recording what survives, not as a separate reviewer or a verdict on the whole system.

Also shown ascritics as thinking traits, critic as thinking trait

Search handlescritical posture, critique as thinking trait, failure question, substrate critic

Generated from the governed public vocabulary for Plectis.

curated system meaning layer Doctrine is not one document but a network of governed artifacts: principles, anti-patterns, concepts, mechanisms, standards, and recorded lessons, each given a name and a place. It captures the operating theory of the system, the rules it holds itself to and the ideas it is built around, so that the reasoning behind a design is written down rather than left implicit. Each piece can be opened on its own and traced back to the source it came from.

ScopeDoctrine covers the explicit-meaning layer of the system and is encountered on the Doctrine page and its individual cards, with cross-references reaching into components, paper modules, and the standards they enforce.

ExampleThe axiom "Derivation before assertion", which holds that a claim should be derived from evidence before it is stated as fact, is one doctrine card: a single named principle in the doctrine layer with its own entry on the Doctrine page.See it live: Derivation before assertionbrowse the curated doctrine cards

Not thisDoctrine is not the source code or the running machinery, and it is not a binding guarantee that the system behaves as described. It is the recorded set of principles and ideas the system is meant to follow, which the components and checks are responsible for actually enforcing.

Reader ruleTreat a doctrine entry as a statement of intent and principle, not as proof that the running code obeys it. It tells you what the system means to do and why; the matching component or check is where that intent is actually carried out.

Also shown asdoctrine layer, principles concepts mechanisms, curated meaning

Generated from the governed public vocabulary for Plectis.

belief-bound action control It works as a chain: evidence sets the status of a claim, the status of that claim sets which actions are permitted, and any unresolved uncertainty stops a change from being made. It would draw together the recorded checks, judgments, appeals, and projection comparisons into claim rows and matching action boundaries, so that the system only acts where its own beliefs are backed and holds back where they are not. Today it exists as a stated target and an alias; the written-up artifact behind it is the Workingness Instrument paper module and a candidate standard.

ScopeThe term covers the runtime layer that would govern action by belief status across the system; a reader meets it in architecture and runtime descriptions and as the forward-looking name for the Workingness Instrument.

ExampleThe Workingness Instrument, written up as a paper module and a candidate standard, is the concrete artifact this term points at: the authored design that an epistemic control plane would one day run as live machinery.See it live: How it fits together (architecture map)see where this runtime layer would sit in the system

Not thisAn epistemic control plane is not an already-running gate that currently decides every action, and it is not a general phrase for the system's overall safety. It is one specific, still-to-be-built layer that would link belief status to permitted action.

Reader ruleTreat it as a planned bridge from self-observation to safe action, not a shipped runtime: where you meet it, expect a description of how belief is meant to gate action, with the live writer still to be built.

Also shown asepistemic_control_plane, belief control plane

Search handlesself-model control plane, workingness control plane

Generated from the governed public vocabulary for Plectis.

bounded class repair When something fails in one place, that failure is taken as evidence about one location and as a question about others: does the same cause sit in sibling files, standards, routes, tests, or generated records. Failure class propagation answers that question by scanning those siblings, stating exactly where the pattern holds and where it stops, and then making a fix that covers the proven extent and no more. A deliberate decision not to widen counts as a valid outcome when it records what was checked and why widening would currently cause harm.

ScopeThe term covers how the system turns a local defect into a bounded, checked repair across related surfaces. A reader meets it in the doctrine and in components such as the Pattern Binding Contract, where a local pattern is bound to its proven extent with a stated boundary rather than patched once or expanded without limit.

ExampleThe Pattern Binding Contract is a concrete instance: it takes an observed pattern, binds it to the sibling surfaces where the same shape genuinely recurs, and fixes the extent of the binding so the repair neither stops at the first case nor spreads past where the pattern holds.See it live: Pattern Binding Contractopen the component that binds a local pattern to its proven class with a stated boundary

Not thisFailure class propagation is not patching only the one spot that broke, and it is not turning a single bug into an unbounded sweep across the whole system. It is a bounded repair sized to the siblings that were actually checked.

Reader ruleWhen you see a fix described as failure class propagation, read what siblings were scanned and where the boundary was drawn: it claims to have repaired a bounded class, not every instance everywhere and not just the one case that was first noticed.

Also shown asfailure_class_propagation, class of failure, failure class

Search handlespatch the class, bounded class repair, local failure global pattern, local failure to global repair

Generated from the governed public vocabulary for Plectis.

local lesson becomes general When work on one part of the system reveals something worth keeping, generalise-up-propagation does two things at once: it preserves the original case as evidence, and it names the broader invariant that case revealed. The general rule it produces carries an applicability boundary and a not-when boundary, so a single instance is never written up as if it held everywhere. It also records which layer of the system owns the new rule, so the lesson lands in a definite home rather than floating loose.

ScopeThe term covers how knowledge moves from specific work into shared doctrine across the system. A reader meets it in the doctrine and propagation rules, where local findings are turned into bounded, reusable invariants.

ExampleAxiom AX-8, provenance propagation and non-interference, is one such durable rule: a lesson about keeping a record of where a result came from, raised to a system-wide invariant with its own stated limits.See it live: Provenance propagation and non-interferenceopen the doctrine rule this propagation produced

Not thisGeneralise-up-propagation is not the same as simply saving or filing a note. It does not assume one case proves a universal truth: the broader rule is only valid with its applicability and not-when boundaries attached.

Reader ruleWhen you meet a rule that arrived this way, check the boundary it states: it was promoted from one concrete case, and it holds only within the limits recorded alongside it.

Also shown asgeneralize_up_propagate, generalise-uppropagate, generalize-uppropagate

Search handlesgeneralise up propagate, generalize up propagate, generalized up-propagation, generalised up-propagation

Generated from the governed public vocabulary for Plectis.

compressed whole from parts A hologram is a layered summary derived from the source. A top band gives the shortest useful view, and any row can be expanded into the detail beneath it. The same tiered behaviour is sometimes named telescope or Russian doll: read the smallest layer first, then open only the part that matters. It is a way to grasp the shape of the system before reading source or running a search.

ScopeThe term covers the navigation and orientation surfaces of the system: the compressed, expandable views a reader meets when browsing components, paper modules, or the architecture map. It is encountered wherever a short row offers to open into deeper detail.

ExampleThe Navigation Hologram Route Plane is a working component that realises this idea: it lays out the system's routes as a compressed, expandable plane that can be opened and inspected.See it live: Navigation Hologram Route Planeopen the component that builds the compressed route view

Not thisA hologram is not a three-dimensional image or an optical effect, and it is not the source itself. It is a layered, expandable summary drawn over the source so the shape of the larger system survives at a small size.

Reader ruleTreat a hologram as a reading surface, not the source of record. Start from the smallest band, expand the one row you need, and follow its evidence commands when a decision needs proof.

Also shown asnavigation hologram, holographic, compiled hologram

Search handlesRussian doll, telescope, telescoping, holographic telescope

Generated from the governed public vocabulary for Plectis.

repo control query spine The kernel sits in front of the deeper source material and hands back compact, bounded answers rather than raw files. Ask it where a subsystem lives, what phase is running, how to route a task, or what the current runtime state is, and it returns a focused view drawn from the underlying records. Its output is a map over deeper source authority, so it points at the real files rather than replacing them.

ScopeThe term covers the local control-and-query program for this system and its commands for navigation, phase, substrate, observation, and status. A reader meets it wherever the pages describe how the system is entered, oriented, and routed.

ExampleIn this system the kernel is the program kernel.py, run with commands such as a navigation or phase query, which returns a structured packet naming what is active and what to read next.See it live: How it fits together (architecture map)see where the control spine sits among the parts

Not thisA kernel here is not an operating-system kernel and not a machine-learning model; it is the system's own local command program that returns structured answers about the system.

Reader ruleTreat the kernel's reply as a view over deeper source, not the source itself: it tells you where to look and what is active, and the files it names are the underlying authority.

Also shown askernel.py, repo kernel, control spine

Search handlesquery spine

Generated from the governed public vocabulary for Plectis.

controlled experiment substrate A laboratory runs a proposed mechanism against a deliberately small, self-contained fixture so the system can see how that mechanism behaves without putting the real files and records at risk. Each run collects records of what happened, names the gaps it found, and can hand back a candidate worth promoting. Its results stand as evidence for that one experiment; they do not by themselves change a standard, a rule, or a release decision.

ScopeThe term covers the experiment-and-evidence lane used when a new mechanism is being trialled before broad adoption. It appears on the architecture and component pages, where a specific laboratory, such as the certificate kernel execution lab, can be opened and inspected.

ExampleThe Certificate Kernel Execution Lab is one such laboratory: it runs the proof-certificate machinery against a contained fixture so its behaviour can be observed and recorded in isolation.See it live: Certificate Kernel Execution Labopen one live laboratory component and see what it exercises

Not thisA laboratory is not the live system itself, and it is not a final result or an approved standard. It is a contained trial whose findings still have to clear the system's gates before they count.

Reader ruleTreat what a laboratory produces as the findings of one bounded trial: useful evidence and a possible candidate for promotion, not a settled standard or a guarantee about the live system.

Also shown aslab, system laboratory

Search handlessystem lab, laboratory probe, lab probe, laboratory packet, laboratory receipt, laboratory ledger, laboratory fixture

Generated from the governed public vocabulary for Plectis.

typed planes and edges The system is not one flat list of rules but a graph of related parts spread across different kinds: a standard, a skill, a paper module, a vocabulary entry, a navigation route, and a runtime surface can all be joined by an edge that states how they relate. The lattice is that whole-system relationship graph. Because the edges are typed, a lesson learned in one place can move to the part of the system that can safely reuse it while its origin and authority stay intact.

ScopeThe lattice covers the relationships between all the named kinds of thing on this site, from components and paper modules to doctrine cards and routes. A reader meets it most directly on the architecture map, where the parts are shown joined together, and implicitly whenever one page links across to a different kind of artifact.

ExampleThe architecture map on this site is a view of the lattice: it lays out the system's planes and units and shows the edges that connect a standard to the skill that applies it, or a route to the component it reaches.See it live: How it fits together (architecture map)see the typed planes and units joined into one map

Not thisA lattice is not a single diagram or a rigid hierarchy of layers stacked one above another. It is the typed web of relationships among the system's parts, where any kind of artifact can link to any other.

Reader ruleWhen something is described as living in the lattice, read it as a position in a connected map rather than an isolated note: it has edges to the standards, routes, and units it relates to, and those edges tell you where else to look.

Also shown assystem lattice, governance lattice, doctrine lattice

Search handlestyped plane lattice, plane lattice

Generated from the governed public vocabulary for Plectis.

portable invariant routing When a fix or insight surfaces in a single file or task, it often encodes a rule that should not stay tied to that one spot. Lattice transposition is the disciplined version of moving it: it keeps the original case on record, names the portable rule, states where the rule applies and where it does not, and deposits it in the narrowest mature plane that can carry it. A friction met while promoting one principle can refine the standard for writing principles; a routing failure can refine a skill and its documentation. The move is only valid if it preserves the source case and respects the authority of the plane it lands in.

ScopeThe term covers how the system turns a one-off lesson into a durable, reusable rule routed to the right governing plane. A reader meets it in the doctrine and routing material, where rules are shown alongside the cases that produced them and the boundaries that limit them.

ExampleThe doctrine card on provenance propagation and non-interference (AX-8) is a concrete instance: it is the rule that a lesson may move between planes only while carrying its origin and without contaminating the plane it enters, which is exactly the discipline lattice transposition follows.See it live: Provenance propagation and non-interferenceopen the doctrine rule that governs how a lesson moves between planes

Not thisLattice transposition is not copying a snippet of code or text from one place to another, and it is not a vague claim that everything in the system is connected. It is the specific, accountable act of lifting a lesson to its underlying rule and routing that rule to the plane that owns it, with the source case kept on record.

Reader ruleWhen you see a rule presented as transposed, check that it cites the concrete case it came from and states its applicability and limits. It is a generalisation that is meant to stay accountable to its source, not a free-floating maxim.

Also shown aslattice-transposition, generalized up-propagation, generalised up-propagation

Search handlesportable invariant routing, cross-plane up-propagation

Generated from the governed public vocabulary for Plectis.

read with currentness The system changes continuously, so a claim that held when it was written can later be out of date while the record of it stays on file. Living system posture keeps both halves separate: the past claim is preserved as a record of what was true then, and current authority comes from the live files and the surface that tracks how fresh each thing is. Reading something under this posture means asking what was true when it was written, what is true now, what changed, and which check proves it.

ScopeThe term covers how every dated artifact on the site should be read, from recorded results and generated pages to doctrine and raw quotes. A reader meets it wherever a record states what a pass found or what the system once contained and wants to know whether it still describes the system today.

ExampleThe evidence page, "What the pass proves", is a concrete instance: it sets out what a given pass actually checked and found at the time it ran, which is the kind of dated record that living system posture asks you to read as evidence from that moment rather than as a standing guarantee.See it live: What the pass proves (evidence)see a dated record of what a pass actually checked and found

Not thisLiving system posture is not a claim that the system is unstable or that nothing on the site can be trusted, and it does not mean old records are discarded. It is the practice of reading each record as tied to a time and confirming current claims against the live source.

Reader ruleTreat any record on this site as carrying a date and a state of the system, not as a permanent truth: it tells you what held when it was made, and a current claim is confirmed against the live source and its freshness check.

Also shown asliving_system_posture, system is always changing

Search handlesalways-changing system, always changing system, change posture, currentness, currentness posture, regime-bound substrate, old regime

Generated from the governed public vocabulary for Plectis.

system movement pattern A mechanism names the working path behind a piece of doctrine or behaviour: what goes in, what is done to it, what comes out, what authority governs it, and how it can fail. It ties an idea to running code, a standard, or a runtime surface, so a claim about how the system behaves can be traced to the steps that actually carry it out.

ScopeThe term covers the "how it works" layer that connects concepts, principles, skills, standards, and code. A reader meets it across the doctrine pages, where each rule is expected to be backed by an explanation of the process that carries it out.

ExampleThe Executable Doctrine Grammar component is a mechanism: it is the surface that requires a piece of doctrine to be run as actual steps before it is treated as authoritative, so the rule is bound to a working process rather than to wording alone.See it live: Executable Doctrine Grammaropen the component that turns a rule into runnable steps

Not thisA mechanism is not a slogan or a name for a behaviour on its own. Calling something a routing or validation step does not make it a mechanism until the inputs, steps, outputs, and failure modes are spelled out and grounded in real code or standards.

Reader ruleWhen a mechanism is described, follow it down to the inputs, steps, and outputs it names, and check that those steps are grounded in real code or standards rather than asserted in the abstract.

Also shown asmech, mech_*, doctrine mechanism

Search handlesmovement

Generated from the governed public vocabulary for Plectis.

governed substrate upkeep Where ordinary navigation reads what is already there, metabolism is the layer that produces and refreshes it. It watches the authoritative source material, queues bounded pieces of work, populates or rebuilds derived surfaces such as generated summaries and indexes, checks the results, and records what it did. It is durable upkeep, not a one-off answer: enforcing standards, refreshing generated views, and repairing scaffolding all run here. It is bounded by design and halts at the point where a human or a higher authority must decide.

ScopeMetabolism covers the maintenance and refresh machinery beneath the system, spanning the lane that turns raw operator notes into structured records, the always-on runtime, and the periodic rebuilds of generated pages. A reader meets it whenever a page notes that a surface is generated, populated, or kept in sync rather than authored directly.

ExampleThe Engine Room Metabolism Runtime is a concrete instance: the working machinery that runs these upkeep loops over the underlying material and keeps derived surfaces current.See it live: Engine Room Metabolism Runtimeopen the runtime that runs the upkeep loops

Not thisMetabolism is not a biological metaphor and not a vague word for activity in general. It is the specific, bounded machinery that refreshes derived surfaces and records what it changed.

Reader ruleWhen something on this site is described as metabolized, take it as a surface that the upkeep loop generated and last refreshed, not source material edited by hand.

Also shown asmetabolic system, metabolism lane, generalized metabolism

Search handlesgeneralised metabolism, surface metabolism, row metabolism, background metabolism, runtime metabolism, system metabolism, raw-seed metabolism

Generated from the governed public vocabulary for Plectis.

browse choices before source Rather than opening the whole codebase to find one thing, navigation presents the system as a series of choices that can be opened in stages: a top-level map, then groups, then individual rows, then the source or evidence behind a row. Each step shows what exists and what it contains before the full text is loaded, so a path through the material can be chosen deliberately. It is the layer that makes the system inspectable in order, from overview down to a single record.

ScopeNavigation covers the orientation surfaces of the site: the architecture and area pages, contents listings, and the staged drilldowns from map to group to row to source. A reader meets it whenever they move between an overview and a specific component, paper module, or piece of evidence.

ExampleThe architecture and navigation area page is one instance: it lays out how the parts of the system fit together and links onward into the specific components and records beneath each part.See it live: Area: architecture & navigationsee the navigation surface that maps the parts and links down to records

Not thisNavigation is not a search box or a website menu bar bolted on for convenience. It is the staged map from overview to source that the system builds over its own files, and a row in it is a pointer to a record, not the record itself.

Reader ruleTreat a navigation surface as a map of what is available, not the thing itself: follow it down to the underlying record before relying on what a row says.

Also shown asnavigate, nav, browse

Search handleschoice surface, option surface

Generated from the governed public vocabulary for Plectis.

gather evidence before deciding Observe is the evidence-gathering half of the observe/apply pairing the system runs. An observe pass learns, maps, compares, or probes a target and writes down what it found: the questions it asked, the files it examined, the responses it got back, a synthesis, and any validation signals. It can run locally or across a bridge of helpers, but it never mutates code or doctrine. Its job is to keep exploration separate from action so a decision rests on collected facts rather than a first guess.

ScopeObserve is a runtime activity in the system's observe/apply cycle. A reader meets it wherever the pages describe how a pass gathers evidence, runs probes, or proves a point before any application step, including the evidence and architecture surfaces.

ExampleThe Tactic Portfolio Availability Probe is one concrete observe: it inspects which proof tactics are available for a target and reports what it found, without itself attempting the proof.See it live: Tactic Portfolio Availability Probesee what an observe pass actually records and proves

Not thisAn observe is not the change itself and not a finished decision. It collects and records evidence; the separate apply step is where anything is altered.

Reader ruleRead an observe pass as a record of what was examined and found, not as a completed change. The work it describes has been looked into, not yet carried out.

Also shown asobserve pass, observe plan, evidence pass

Search handlesprobe

Generated from the governed public vocabulary for Plectis.

named missing context Pages and browse rows on this site are compressed views of a much larger body of source material. An omission receipt is the part of such a row that keeps the compression honest: it names what was dropped, such as the underlying source bodies, deeper relationships, or fuller command output, gives the reason that omission is acceptable for a quick-scan row, and points to the drilldown that recovers the complete material. It lets a row be useful for choosing what to open without quietly pretending to be the whole story.

ScopeThe term covers row-level truth boundaries throughout the system's compressed navigation, browse listings, and summary cards. A reader meets it wherever a short row stands in for fuller source material and carries a pointer back to that material.

ExampleThe doctrine card "Preserve provenance across every boundary" is a concrete instance: it holds the rule that a compressed surface must always keep a path back to the source it summarises, which is exactly what an omission receipt records on an individual row.See it live: Preserve provenance across every boundaryopen the doctrine rule that an omission receipt enforces on each row

Not thisAn omission receipt is not an error message, a disclaimer, or an admission that something is broken. It is a deliberate, structured record of what a compressed row leaves out and how to recover it.

Reader ruleTreat the omission receipt on a row as the row's own statement of its limits: it tells you what is not shown and how to reach the full source, so follow that pointer when you need the complete picture rather than assuming the short row is everything.

Also shown asomission_receipt, omission boundary

Search handlesomitted context receipt, named missing context, row omission receipt

Generated from the governed public vocabulary for Plectis.

bounded operator-intent proxy When the system hands a task to a separate worker, such as a chat model or coding agent, it sends a packet that holds the purpose, the relevant doctrine, worked examples, the output shape, and the constraints. The worker runs as an operator proxy: it can do real work because the packet makes the intent executable, but its remit is fixed to that one task. Choosing what context to send, validating the result, and deciding whether the output enters the system stay with the owning side, not the proxy.

ScopeThe term covers the bounded delegation role used when the system routes a task to an external worker such as a chat model or coding agent. A reader encounters it on the pages describing how the system works with coding agents and runs prepared missions.

ExampleA concrete instance is a chat model that receives a packet defining one message-writing mission, drafts the message inside those limits, and returns it for the owning side to check and admit, never acting beyond that brief.See it live: With a coding agentsee a worker run a prepared task on the operator's behalf

Not thisAn operator proxy is not the operator and not an autonomous agent that sets its own goals or changes the system's rules. It is a worker running one prepared task within fixed limits, whose results take effect only once the owning side admits them.

Reader ruleTreat an operator proxy's output as work done to order, not as a decision made by the operator. It is bounded to the task it was given, and it becomes part of the system only after the owning side validates and admits it.

Also shown asoperator_proxy, subconscious bridge, message mission proxy

Search handlesbridge proxies the operator, bridge operator proxy, operator-proxy bridge

Generated from the governed public vocabulary for Plectis.

direct operator expression Operator voice is the unmediated expression of the person who runs the system: raw seed paragraphs, spoken notes, and direct instructions, recorded as they were given. It holds authority over every later artifact, so paper modules, standards, and agent-written summaries may compress or route it but can never replace or contradict it. The raw record is kept append-only for this reason: it is the layer everything else answers to.

ScopeOperator voice covers the raw seeds, voiced paragraphs, and direct instructions that seed the system. A reader meets it behind the doctrine and component pages, which are projections drawn from it, and most directly in the loop that turns this voice into doctrine.

ExampleThe Voice To Doctrine Self Improvement Loop is a concrete instance: a component that takes the operator's recorded voice and distils it into doctrine while preserving the original wording, so you can see the raw human input on one side and the compressed rule on the other.See it live: Voice To Doctrine Self Improvement Loopopen the component that turns recorded operator voice into doctrine

Not thisOperator voice is not the polished doctrine, standards, or agent-written summaries on the site. Those are projections compressed from it. It is also not a Bridge proxy speaking on the operator's behalf: it is only what the operator himself said directly.

Reader ruleWhen something is marked as operator voice, treat it as the original human source, above any summary or agent rephrasing of it. If a later page conflicts with it, the operator voice is the one that holds.

Also shown aswill voice, direct voice

Search handlesvoice authority

Generated from the governed public vocabulary for Plectis.

selectable row surface An option surface sits between the top-level Kind Atlas and the underlying source material. For a chosen kind of artifact, such as components, paper modules, or doctrine cards, it enumerates the available rows cheaply, lets one be selected by its stable id, and shows a compact card for that row that states what is and is not included and how current it is. Only after a row is chosen does it hand off to the authoritative standard, registry, skill, or paper module behind it.

ScopeThe term covers the standard-owned row-and-card browse mechanism used across the system's navigable kinds. A reader meets it wherever the public pages present a list of components, paper modules, or doctrine cards that can be opened one at a time.

ExampleThe Navigation Hologram Route Plane is the routing layer in which option surfaces operate: the place where artifact rows are listed by kind and a stable id is selected before the authoritative source is opened.See it live: Navigation Hologram Route Planeopen the routing plane where rows are listed and selected by id

Not thisAn option surface is not a keyword search box and not the source files themselves. It is a fixed catalogue of rows you select from by id, sitting one layer above the authority it links to.

Reader ruleTreat an option surface as a catalogue for finding and selecting one row, not as the final authority on that row. The card it shows is a summary with its own currentness and omission notes; the binding detail lives in the source it links to.

Also shown asoption_surface, standard option surface

Search handlesstandard-owned option surface, row surface, selectable row surface, row set

Generated from the governed public vocabulary for Plectis.

subsystem ontology packet Each paper module covers a single subsystem and records its intent, its shape and boundaries, the rules that must hold, the source files it points down to, its current state, what it still owes, and how it is kept fresh. It points downward to source and upward to the principles, components, and standards the area connects to, so an area can be understood without reopening every file. It is an explanation of running machinery, not the machinery, and not the final authority over it.

ScopePaper modules cover the named subsystems of the system, one packet each, and a reader meets them on the paper modules pages where each area is laid out as its own entry.

ExampleThe Verifier Lab Kernel paper module is one such packet: it explains the subsystem that runs proof and verification checks, summarising what that area does, where its code sits, and what state it is in.See it live: Verifier Lab Kernelopen one subsystem packet in full

Not thisA paper module is not the source code of a subsystem and not the authority over how it behaves. It is a structured description of one area that points to the source, and it can fall out of date until it is refreshed.

Reader ruleTreat a paper module as an orientation for one area, then check the source it points to when a detail is load-bearing. It describes a subsystem at a point in time and can lag the code if it has not been refreshed.

Also shown aspaper_module, subsystem paper, ontology packet

Search handlessubsystem ontology

Generated from the governed public vocabulary for Plectis.

vision activates work Passion is one of the named traits the system uses to describe disciplined human judgment, alongside care and common sense. It is the trait that resists flattening a request into sterile task completion: it carries the person's theory, urgency, and meaning into the action so the action stays intelligible. It is bounded, not free rein. Whatever it motivates must still be backed by a source and constrained by the standards, so the live purpose is preserved without becoming unchecked enthusiasm.

ScopePassion appears wherever the system describes how human judgment and operator intent are preserved through disciplined process: in its doctrine on partiality, refusal, and authority, and in the surfaces that turn live intent into source-backed, navigable work rather than enthusiasm asserted without backing.

ExampleA clear instance is the doctrine card on typed partiality and refusal, which holds a strong, motivated position while still pinning that position to evidence and an explicit boundary, showing stake and discipline operating together.See it live: Typed partiality and refusalopen one doctrine card where motivated judgment is held to evidence and a stated boundary

Not thisPassion is not hype, enthusiasm for its own sake, or permission to assert something without backing. It is motivated judgment that still answers to the standards and the source.

Reader ruleWhen you see passion named, read it as the stake and intent behind a piece of work, held alongside the evidence rather than in place of it. It signals why something matters; it does not on its own license a claim.

Also shown aspassion register, vision activation

Search handlesoperator stake, why this matters, care and passion

Generated from the governed public vocabulary for Plectis.

compact expandable path id A path handle separates the identity of a reference from the place a thing is stored. Instead of repeating a long or unstable filesystem path everywhere, the system keeps one governed entry that records where the target lives now, what job it plays, how to display it, how fresh it is, which older references still point to it, and the command that expands it back to the full path. Because the handle stays stable while the underlying location can move, it lets the system keep packets compact and references intact without renaming files on disk.

ScopePath handle belongs to the system's navigation layer. A reader encounters it wherever a short, linkable name appears in place of a long storage path, and it sits behind the architecture map that shows how files and locations are wired together.

ExampleIn this system a paper module such as the Navigation Hologram Route Plane is reached through a stable handle that expands to its underlying source file, rather than by quoting the full path to that file.See it live: Navigation Hologram Route Planesee how files and locations are wired into the system

Not thisA path handle is not a symlink and not just a nickname for a file. It is a governed navigation entry that records role, freshness, redirects, and an expansion command, so the reference survives even when the storage location moves.

Reader ruleWhen you meet a path handle, treat it as a stable pointer rather than the location itself: it names where the target lives now and carries the command to expand it, while old references it lists still resolve to the same target.

Also shown assemantic path handle, path alias, path alias registry

Search handlesstorage path handle, path ref, handle registry

Generated from the governed public vocabulary for Plectis.

future capable agent sibling The system is built to be operated by capable AI coding agents, and a peer is one such agent considered in relation to the others. When an earlier agent records a piece of judgment it learned, a later peer can pick that lesson up and use it. The transfer is agent to agent: it carries practical know-how between siblings of comparable capability, and it sits below the human operator's own words and below the system's settled doctrine until it has been reviewed and adopted.

ScopeThe term covers the future-facing relationship between the AI coding agents that operate this system. A reader meets it wherever the pages describe how agents hand work and learned judgment to one another, most directly on the page about working with a coding agent.

ExampleThe "With a coding agent" page is a concrete instance: it describes how a capable agent like Codex or Claude takes up this system and continues work that an earlier agent began, which is precisely the peer relationship.See it live: With a coding agentsee how one capable agent picks up another's work

Not thisA peer is not the human operator and not a fixed rule in the system's doctrine. It is a comparable coding agent, and the judgment it passes on stays advisory until it has been reviewed and adopted.

Reader ruleWhen something is marked as coming from a peer, treat it as one capable agent's preserved judgment offered to another, not as the operator's instruction or as confirmed doctrine.

Also shown asfuture peer, Codex peer, Claude peer

Search handlesType A peer

Generated from the governed public vocabulary for Plectis.

peer teaches future peers When an agent working in this system learns something genuinely useful but not yet settled enough to become a formal rule, it writes that lesson down as a peer-propagate record so a later agent can find and apply it. Each record cites where the lesson came from, where it applies, where it does not, and how confident it is. It is held as candidate knowledge passed between agents, kept distinct from the operator's own words, from private memory, and from the system's active rules.

ScopeThe term covers the lane by which reusable agent judgment is preserved and handed forward between Type A agents such as Codex and Claude. A reader meets it on the doctrine page, where the governing rule is provenance propagation and non-interference.

ExampleThe axiom "Provenance propagation and non-interference" (AX-8) is a concrete instance: it sets the rule that a lesson may be carried forward to later agents only with its origin attached and without overriding existing authority.See it live: Provenance propagation and non-interferenceopen the doctrine card that governs how lessons pass between agents

Not thisA peer-propagate record is not an instruction from the operator, not a private memory note, and not an active rule the system enforces. It is candidate knowledge one agent records for later agents, carrying its own source and limits.

Reader ruleTreat a peer-propagate record as one agent's tested advice to the next, not as a settled rule: check what it says it applies to and where it says it does not before leaning on it.

Also shown aspeer propagate, PEER propagation

Search handlestribal knowledge

Generated from the governed public vocabulary for Plectis.

bounded family work packet A phase is how the system breaks a broad area of work into a single resumable unit. Each phase narrows a wide family objective into a concrete sequence of waves, revisions, ledgers, and a closeout record, and it preserves the current objective, the execution mode, the active wave, and the legal next steps so the work can be picked up exactly where it was left.

ScopePhase covers the system's unit of in-progress work and its resumable state. A reader meets it in the architecture map and in the runtime that keeps phases continuous across sessions, and in identifiers carrying names like subphase, phase packet, or phase workspace.

ExampleThe Bridge Phase Continuity Runtime is a concrete instance: it is the component that keeps a phase's state intact so an interrupted phase can be resumed rather than restarted.See it live: Bridge Phase Continuity Runtimeopen the component that keeps a phase resumable across sessions

Not thisA phase is not a project milestone on a calendar or a stage in a release schedule. It is a concrete, resumable execution workspace holding one objective and its current state.

Reader ruleWhen you meet a phase, read it as the live container for one stretch of work: it tells you what is currently being done, how far it has got, and what may happen next, rather than describing the system as a whole.

Also shown assubphase, phase packet, phase workspace

Generated from the governed public vocabulary for Plectis.

durable operating law A principle states a rule that holds across many cases rather than a fix for one situation, such as "status fails closed" or "derive before you assert". Each principle carries not just the rule but the design instinct behind it: the underlying tradeoff and the reasoning a later decision should reuse when a new case differs from the one that first prompted it. Principles are more stable than a single observation and more general than a mechanism, and each is grounded in recorded evidence and a curation history.

ScopePrinciples appear throughout the doctrine and rules-and-ideas pages, where each is shown as a numbered, named rule with its rationale; they are the general laws the more specific anti-patterns, mechanisms, and components are measured against.

Example"Status fails closed" is a principle: it commits the system to treating an unknown or unproven status as not-passing rather than assuming success, so that absence of evidence never reads as a green light.See it live: Status fails closedopen one stated principle with its rationale

Not thisA principle is not a passing slogan, a personal preference, or a description of one feature. It is a governed, evidence-backed rule that holds across cases, distinct from the narrower mechanisms and anti-patterns it governs.

Reader ruleRead a principle as a standing commitment the system holds itself to, and look at the rule it states and the reason given for it, not just its label.

Also shown aspri, pri_*, operating law

Search handlesrule, design intuition proxy, primitive choice proxy

Generated from the governed public vocabulary for Plectis.

missing row support The system arranges its artifacts into kinds and lets each kind be enumerated as stable rows that can be selected and drilled into. A profile gap marks a kind that has a registry, source files, or generated index entries but no fully supported rows yet, so it is visible at the top level without being claimed as fully navigable. It is a deliberate marker of navigation debt: a way of saying the support is incomplete rather than papering over the difference between data that exists and a surface that can honestly list it.

ScopeThe term covers the boundary between artifacts the system can see and artifacts it can list as selectable rows. A reader meets it in the navigation and architecture surfaces, where some kinds are marked as fully browsable and others carry this gap.

ExampleIn the architecture map, a kind that appears in the system inventory but has no completed flag-and-card row support is shown as carrying a profile gap, which is why it is named at the top level yet cannot be drilled into member by member.See it live: How it fits together (architecture map)see where kinds become browsable and where a gap stands in

Not thisA profile gap is not a bug, a missing file, or a broken page. It is a recorded marker that a kind's row-level browsing has not been finished, even though the kind itself exists and is visible.

Reader ruleTreat a profile gap as an honest "not yet browsable here" sign, not a defect: the kind is real and visible, but its row-level listing has not been finished, so do not expect to enumerate or open every member of it.

Also shown asprofile_gap, projection gap

Search handlesoption-surface gap, missing row support, navigation debt receipt, rowability gap

Generated from the governed public vocabulary for Plectis.

operator voice authority layer The raw seed holds the operator's voice in its first form: the intent, the recurring phrases, the changes of mind, and the provenance of an idea, written down before any tidying. Indexes, shards, principles, and paper modules elsewhere in the system are summaries drawn from it; the raw seed is the thing they summarise, and it is never overwritten or compressed away. When a higher layer needs to be checked against what was actually meant, the raw seed is the bottom authority it answers to.

ScopeThe raw seed covers the operator-voice source material that the system's doctrine, principles, and components are generated from. A reader meets it on the pages that show how recorded voice becomes structured doctrine, and in references back to source provenance.

ExampleThe Voice To Doctrine Self Improvement Loop is one place the raw seed is visible in use: it takes recorded operator voice as its input and turns it into structured doctrine, so the seed is the raw material entering one end of that loop.See it live: Voice To Doctrine Self Improvement Loopopen the component that turns recorded operator voice into doctrine

Not thisA raw seed is not a polished mission statement, a marketing narrative, or the system's final doctrine. It is the unedited source voice that those later, tidier layers are derived from.

Reader ruleTreat the raw seed as the original wording and the summaries above it as maps of that wording. When the two seem to disagree, the raw seed is the record of what was actually meant.

Also shown asraw_seed, operator voice, Will voice

Search handlesvoice authority

Generated from the governed public vocabulary for Plectis.

portable inspection guide A reader packet is the compact starting document handed to someone, or to an automated assistant, who is opening the public slice for the first time. It carries the routes worth following, brief descriptions of components and glossary rows, links back to the underlying source files, and an explicit note of what it does and does not cover. It is reproducible and built from the source, so its job is to point at where to inspect rather than to stand in for the records it summarises.

ScopeThe term covers the generated digest and review artifacts that orient a reviewer at the public source slice, such as the AI reader digest and the review packet. A reader encounters it as the entry-and-orientation surface that hands off into components, routes, and source files.

ExampleThe Cold-Reader Route Map is a reader packet: a single artifact that lays out the first routes a newcomer should follow into the public slice and links each one back to its source.See it live: Cold Reader Route Mapopen the packet that routes a first-time reader into the source

Not thisA reader packet is not source authority and not proof that a reviewer read or endorsed the project. It is a generated map whose summaries hold only as far as the source records they link to.

Reader ruleFollow a reader packet through to the source records it links rather than treating its summaries as the final word. It tells you where to look and where its own boundaries are.

Also shown asreader digest, review packet

Search handlesAI handoff, copy packet, orientation packet

Generated from the governed public vocabulary for Plectis.

typed storage rename proof When a file or directory in the source is renamed, the receipt is the artifact that makes that rename auditable and reversible. It records the scope of the change, the evidence that the rename gate was satisfied, the post-rename tasks, and closure notes. Receipts move through fixed states, planned, blocked, in progress, completed, and reverted, so the history of a rename is legible from a single object rather than reconstructed from the file system. A completed receipt is evidence the migration happened safely; a blocked receipt is the honest record that it is not yet safe to proceed.

ScopeThe term covers governed renaming of storage paths across the system. Receipts live under state/semantic_naming/rename_receipts/ and follow a fixed standard; a reader encounters the concept wherever a rename is described as governed, gated, or held.

ExampleThe planned receipt for renaming the EPHEMERAL.md storage path, held in a blocked state because a gate precondition was not yet met, is a concrete rename migration receipt naming the outstanding condition rather than performing the rename.See it live: Proof-Derived Governed Mutation Authorizationopen the rule that ties a mutation to a typed proof that its gate was satisfied

Not thisA rename migration receipt is not a commit message or an after-the-fact changelog note. It is a typed, governed object recorded before the rename is made, and it can carry a blocked state that records a rename deliberately not performed.

Reader ruleCheck a rename migration receipt's state and its named gate evidence before treating a rename as settled. A blocked receipt means the change was deliberately not made, and it names the precondition that is still missing.

Also shown asrename receipt, migration receipt

Search handlesstorage rename receipt, rename gate receipt, rename proof, planned rename, planned blocked rename

Generated from the governed public vocabulary for Plectis.

choose the right path The system holds far more surfaces, such as documents, components, paper modules, standards, and source records, than anyone can open directly. Routing turns a situation into a ranked, source-linked set of options, each with a reason and a cost, so the right starting point can be chosen first. It selects the path; it does not make the chosen summary authoritative, and the underlying source still has to be opened to confirm what it claims.

ScopeRouting covers the decision of where to look across the whole site, from a docs lookup to a paper-module or component pointer to a fallback by meaning. A reader meets it whenever a query or link hands them a chosen path with a reason rather than dropping them straight into raw source.

ExampleThe Navigation Hologram Route Plane is one concrete instance of routing: it is the surface that turns a situation into ranked, source-linked options so the smallest useful next step can be chosen before any underlying file is opened.See it live: Navigation Hologram Route Planeopen the live route-selection surface as one component

Not thisRouting is not the content itself and not a guarantee that the surface it picked is correct. It chooses and ranks where to look; the underlying source still has to be opened and checked.

Reader ruleWhen a page or tool routes you somewhere, treat that as a suggested starting point with its stated reason, not a final answer; the surface it points to is where the real content lives.

Also shown asroute, route graph, semantic routing

Search handlesdocs route

Generated from the governed public vocabulary for Plectis.

bounded row transition Rather than handing a broad instruction like "repair every finding" or "use the providers" straight to an automated worker, the system first breaks that pressure into row jobs. Each row job pins down exactly one target and one operation, states the authority ceiling it must stay within, the validation it has to satisfy, and the gate it must clear before its result is promoted. It is a description of one bounded task, settled in advance, not the act of running it.

ScopeRow job is a runtime term. A reader meets it wherever the system turns a large request into discrete, checkable pieces of work: provider-driven passes, bulk repair of findings, and pipeline-style campaigns that fan many small changes across workers.

ExampleThe Bounded Autonomy Campaign Packet is a concrete instance: a packet that frames a run as a set of bounded, pre-specified jobs, each with its own target, limits, and validation, so the work can proceed without open-ended authority.See it live: Bounded Autonomy Campaign Packetopen one live component that packages bounded, pre-specified jobs

Not thisA row job is not a running process, a scheduler, or a grant of broad permission to act across the system. It is the bounded specification of one task, fixed before any worker runs.

Reader ruleRead a row job as the full specification of one small, scoped change: what it touches, what it is permitted to do, and the check it must pass. It governs that one task and grants no wider authority over the system.

Also shown asrow-job, row_job

Search handlesmetabolism job, worker affordance packet, bounded row job, provider row job, transform job candidate, validation contract, validation_contract

Generated from the governed public vocabulary for Plectis.

selectable row readiness Rowability is the test of whether a category of objects in the system, such as its components or its paper modules, is ready to be navigated as a list. A rowable kind has a place in the system's index of kinds, gives every item a stable id, exposes short summary and detail views without expensive work, marks each item's source and freshness, and states honestly anything it has left out, so the items can be reached by browsing and selecting rather than by guessing search terms. A registry or a source file simply existing is not enough: the kind becomes rowable only once it can be listed, selected, and traced back to source in this way.

ScopeRowability covers the navigation layer of the system: the index of kinds, the listing of each kind's items, and the route from a listed row back to its source. It is encountered wherever items are presented as browsable, selectable lists, such as the components and paper-module index pages.

ExampleThe components index page is a concrete instance of rowability: every component in the system appears as a selectable row carrying a stable identifier and a short summary, and each row opens to fuller detail and a path back to its source.See it live: All componentsbrowse a kind laid out as selectable rows

Not thisRowability is not a search feature or a filter box. It is the prior condition that lets items be listed and selected by stable rows at all, without keyword search, and traced back to their source.

Reader ruleWhen a kind on this site is described as rowable, you can browse and select its rows directly rather than searching for them; follow any row back to its named source before treating the short summary as the full truth.

Also shown asrowable, rowable control spine

Search handlesrowability plane, rowability before retrieval, selectable row readiness

Generated from the governed public vocabulary for Plectis.

names carry system role Under semantic naming, a name is a compact record rather than an arbitrary tag. From the name alone you can infer the artifact's kind, its job, the authority plane it acts on, and how far you can trust it, before opening the source. Each name compresses these facts in a fixed order, so the smallest reading gives the role and a longer reading gives the detail. A name has several layers, including a stable identifier, a storage path, a display label, and aliases, and these can change independently.

ScopeSemantic naming governs how every artifact in the system is named: components, paper modules, doctrine cards, routes, and files. A reader meets it whenever a name on the site or in the source encodes role, authority, or lifecycle rather than being a plain label.

ExampleThe doctrine card "Executable grammar before doctrine authority" (AX-11) is a concrete instance: its identifier and title fix what the card governs and the authority it carries, so the name states its role before the body is read.See it live: Executable grammar before doctrine authorityopen one named doctrine card whose identifier and title carry its role

Not thisSemantic naming is not a style preference about which word reads best, and it is not mere file tidiness. It is a grammar in which the name encodes the artifact's kind, authority, and lifecycle, so the name is load-bearing information, not decoration.

Reader ruleRead a name as a claim about what the artifact is and what it may do, and trust the stable identifier over the display label or alias when they differ.

Also shown asnaming grammar, file naming system

Search handlesnaming principle, names as affordance rows, role-first naming, semantic filenames, governed naming, root invocation shim, root shim

Generated from the governed public vocabulary for Plectis.

agent operable procedure Where a component is a unit of running machinery, a skill is a unit of action: a written-down operating procedure that tells an agent which task shape it matches and the steps to follow. Each skill carries a trigger that says when it applies, an ordered workflow, the limits it must stay inside, and discovery metadata so it can be located in the system's registry. The registry entry routes an agent to the right skill; the skill file then carries the actual procedure, with links out to the standards and modules that grant it authority.

ScopeSkills are the action vocabulary of the system, sitting alongside its components and doctrine. A reader meets them where the public pages describe how an agent works through a task, most directly on the page covering use with a coding agent.

ExampleThe procedure for working through a task with a coding agent is a skill: it names the situation it fits, lays out the steps to follow, and states the constraints that bound them, so the agent can run it without rederiving the workflow.See it live: With a coding agentsee a skill that drives a coding agent through a task

Not thisA skill is not a personal talent, a clever trick, or a feature being advertised. It is a recorded procedure with named triggers, defined steps, and stated limits that an agent runs.

Reader ruleTreat a skill as a procedure with a stated scope: it applies to the task shape named in its trigger and runs within the constraints it declares, not as general permission to act.

Also shown asprocedure, agent skill, capability

Search handlesworkflow skill

Generated from the governed public vocabulary for Plectis.

bounded public source The published repository does not contain the whole working tree. The source slice is the portion that has been exported into the public repository, so the source-linked components, packets, and routes on this site can be opened and checked against real code. The cut is deliberate and stated, so what is available to inspect is clear and nothing unpublished is implied to be present.

ScopeThe term covers the published subset of source behind the public pages. A reader meets it wherever the site links a component, paper module, or route back to its underlying code, and most directly on the Source and license page.

ExampleThe Plectis public repository is the source slice that backs the hosted reader map: the files it contains are the same ones the public pages are generated from and link to.See it live: Source & licensesee the published source boundary and what it covers

Not thisA source slice is not the entire working tree and not every unpublished ledger or route. It is only the defined subset of source that has been published for inspection.

Reader ruleTreat the source slice as the part you can actually open and verify. It backs the public objects on the site, but it is not the whole codebase, so unpublished routes, ledgers, and operator context will not be found within it.

Also shown aspublic source slice, source-linked slice

Search handlesopen source slice, public repository slice

Generated from the governed public vocabulary for Plectis.

schema backed contract authority Each kind of governed artifact in the system, such as a component record, a paper module, or a doctrine card, has a standard that states its grammar: the fields that matter, the authority posture that applies, and the checks a change must pass. Because a standard is itself a structured file rather than prose advice, it can be validated automatically, and an artifact can be confirmed to conform to it. It encodes not just form but intent, lifecycle, and how the artifact is found, so the shape of a thing does not have to be inferred by reading examples.

ScopeStandards underlie every governed artifact kind on this site. The idea sits behind any component, paper module, or doctrine card, since each conforms to a standard; the registry of them lives in the source under codex/standards.

ExampleThe Executable Doctrine Grammar component is a concrete standard: a JSON-first contract that sets the required shape, authority, and validation rules for a kind of doctrine artifact so it stays machine-readable and governable.See it live: Executable Doctrine Grammaropen one standard as a live component

Not thisA standard is not a recommendation, a style preference, or a benchmark score. It is a structured contract that defines and governs the shape of one kind of artifact.

Reader ruleWhen something is governed by a standard, the standard is the authority on its shape and rules: it states which fields and checks the artifact is held to, rather than leaving them to be inferred from a single instance.

Also shown asstd, schema, contract

Search handlesartifact standard

Generated from the governed public vocabulary for Plectis.

bounded phase working seed A synth seed sits between the system's broad, lasting statement of intent and the moment-to-moment execution of one phase. It carries the goal, the reason the work is happening now, the success criteria, the relevant files, the wave, and the supporting context needed to act without rereading everything upstream. It is deliberately disposable: it is the authoritative model for the phase it describes and is meant to be replaced as the work moves on, not preserved as the system's permanent voice.

ScopeThe synth seed covers the planning and execution of one phase or subphase: its goal, success criteria, files, and wave. It is encountered where phase work and continuity across phases are described, alongside components that carry phase state forward.

ExampleThe Bridge Phase Continuity Runtime is a concrete place this appears: it is the component that carries phase working state across a continuity boundary and checks that the synthetic continuity between phases holds.See it live: Bridge Phase Continuity Runtimeopen the component that carries phase working state across a continuity boundary

Not thisA synth seed is not the system's permanent statement of intent and not a finished specification. It is a disposable, phase-scoped working model that is replaced as the work advances.

Reader ruleTreat a synth seed as the live brief for the phase it names, accurate as of that phase and no wider. It states what one slice of work is trying to do, not the system's lasting intent.

Also shown assynth_seed, synth_seed.json, synth_seed.md

Search handlesphase whiteboard

Generated from the governed public vocabulary for Plectis.

beliefs with reasons Instead of holding facts as one flat, undifferentiated pile, the system records for each claim its evidence, its dependencies, its current status, its appeal state, the conditions that would invalidate it, and the actions it does or does not license. A receipt from a check, a model's output, a generated page, and a doctrine commitment therefore do not share one indiscriminate authority. The standing question is always what is believed now, why, what would overturn it, and what stays blocked while uncertainty remains.

ScopeTruth maintenance covers how beliefs, evidence, and their dependencies are tracked across the system's control plane, separating receipts, model outputs, generated projections, and doctrine commitments so none borrows another's authority. A reader meets it wherever a claim is shown with its supporting evidence, its status, or the conditions under which it would be withdrawn.

ExampleThe Belief-State Process Reward Replay component is one concrete instance: it tracks a belief across a sequence of steps, scoring each step against what the belief should have been at that point and replaying the trajectory to see where a belief was wrongly held or wrongly dropped.See it live: Belief State Process Reward Replayopen one component that tracks and scores a belief across steps

Not thisTruth maintenance is not a guarantee that the system's beliefs are correct, and it is not a single switch that marks something true or false. It is the ongoing record of why each belief is held and what would change it.

Reader ruleWhen a belief on this site is presented as held, treat it as held for stated reasons and only until those reasons are undercut: look for what it depends on and what would invalidate it, rather than reading it as fixed.

Also shown astruth-maintenance, truth_maintenance

Search handlestruth-maintenance plane, belief maintenance

Generated from the governed public vocabulary for Plectis.

substrate-native actor Type A describes a shape of actor, not a quality ranking. It is the lane with live-substrate authority: it can read the working files on disk, run commands, make edits under the system's gates, check its own work, and feed what it learned back into the shared records. Its freedom is bounded by the latest instruction it was given, the limits of what it is allowed to change, the standards, and the requirement to validate, roll back, and leave a record. Controller sessions are Type A; a tool-using helper agent with live access to the repository is a delegated Type A.

ScopeType A is one half of the actor classification used across this system, paired with Type B. A reader meets it wherever the pages describe who or what is doing the work: coding agents, controller sessions, and tool-using subagents that act on the repository under its gates.

ExampleA coding-agent session that opens the repository, reads its current files, runs checks, makes edits under the gates, and commits the result is a Type A actor; the "With a coding agent" page shows one in operation.See it live: With a coding agentsee a Type A actor operating on the live system

Not thisA Type A is not a top capability tier or a mark of seniority, and it is not simply "the controller": a tool-using helper agent with live access to the repository is also Type A, while a capable actor that only reads prepared material without live private state or change authority is not.

Reader ruleWhen something is marked Type A, take it as an actor operating on the live system with real power to change it, kept inside defined gates, rather than a measure of how capable or senior that actor is.

Also shown astype_a, type-a

Search handlessubstrate-native actor, live substrate actor, controller agent, tool-using controller, iterative controller, harness agent

Generated from the governed public vocabulary for Plectis.

judgment grows from traits When an agent reads this system as a body of rules, standards, and recorded state, Type A judgment is the part of its work that is not mechanical: spotting a missing route, a standard that no longer matches reality, or a local lesson worth carrying back into the shared rules. It is a small, open set of traits rather than a fixed list of virtues, with attention and care as early examples, and it is meant to be traceable rather than a passing mood.

ScopeType A judgment covers the agent-side qualities of working over the system, such as common sense, care, and a critic's eye, and a reader meets it on the pages describing how agents operate over the system, particularly the coding-agent walkthrough.

ExampleA coding agent working through this system pauses on a standard that no longer matches the code, notices the gap, and records where the correction belongs instead of carrying on regardless; that act of noticing and routing is Type A judgment.See it live: With a coding agentsee an agent exercising this judgment over the system

Not thisType A judgment is not a fixed checklist of virtues an agent is graded against, and it is not a free-floating personal opinion; it is discernment that stays anchored to the system's own rules and records.

Reader ruleWhere the site refers to Type A judgment, treat it as the agent's discernment exercised on this material, grounded in the system's rules and records, not as an unaccountable opinion.

Also shown astype-a judgment, agent judgment

Search handlesjudgment traits, thinking traits, type a common sense, common sense care passion, care and passion, care + passion, karen passion

Generated from the governed public vocabulary for Plectis.

judgment governs unsettled grammar Most upkeep in the system runs along fixed tracks: a known job, a validator, a row to patch. Type A metabolism is what runs when no such track exists yet. It takes a broad, ambiguous situation and collapses it into something bounded and reusable, such as a named rule, a standard, or a repaired scaffold, while preserving the original situation, the limit of what it is allowed to decide, its checks, and a way to roll back. It is the system changing its own rules rather than just applying them, so it is treated as expensive and powerful.

ScopeThe term covers the governance-and-decision layer of the system's self-maintenance, as distinct from routine population work. A reader meets it on the architecture map and in the engine-room runtime where unsettled grammar is resolved before work is delegated downstream.

ExampleThe Engine Room Metabolism Runtime is a concrete instance: the runtime where the system processes unsettled grammar, resolving contradictions and naming primitives under validation before handing routine work to the lower-agency lane.See it live: Engine Room Metabolism Runtimeopen the runtime where unsettled grammar is resolved

Not thisType A metabolism is not the routine maintenance lane that applies rules already in place, and it is not a biological process. It is the decision layer that sets new rules under validation when none exist yet.

Reader ruleWhen you meet Type A metabolism, read it as a record of judgement applied where the rules were still open: the system deciding a new boundary under validation, not running a routine job. The decision it reached is what makes the later routine work cheap.

Also shown astype_a_metabolism, Type-A metabolism

Search handlescontroller metabolism, judgment metabolism, grammar metabolism

Generated from the governed public vocabulary for Plectis.

care and judgment register It is one of two registers the system distinguishes. A Type A agent is a high-agency controller, a coding agent or its operator, acting on the system from the inside; the register describes how that controller is meant to behave across a piece of work. The behaviours are concrete: steward and thicken the files and records it edits, watch for drift between a summary and what it describes, use what it builds, and pass any local discovery upward through the narrowest honest channel. It is a posture, composed from named judgment traits like care, common sense, and critic stance, not a single tool or a step in a checklist.

ScopeThe term covers the conduct expected of capable controlling agents, the coding agents and operators that act on the system, and appears wherever the pages describe how such an agent stewarded the substrate, spotted findings, and propagated them. It is encountered most directly on the page describing work alongside a coding agent.

ExampleThe conduct shown on the "With a coding agent" page is a concrete instance: an agent reads the substrate, makes a bounded change, records what it learned, and routes that finding into a durable plane rather than dropping it.See it live: With a coding agentsee a capable controller working the substrate in this register

Not thisA Type A operating register is not a personality, a tone of voice, or a marketing claim about enthusiasm. It is also not a passive end-user mode; it describes a controller acting on the system, with the duty to steward what it touches and to route what it finds.

Reader ruleWhen a page describes work in the Type A register, read it as the controller's own account of how it operated: what it stewarded, what it noticed, and where it routed each finding. The register tells you the standard of conduct behind the work, not a guarantee about any single output.

Also shown astype_a_operating_register, operational register type a care passion

Search handlestype-a operating register, type a useful findings, useful findings register, care passion common sense judgment packet, care and passion, care + passion, karen passion

Generated from the governed public vocabulary for Plectis.

external or injected-context cognition Type B is one of two actor shapes the system recognises. A Type B actor reasons through a chat window, a browser session, a provider or web API, or any channel where it sees only the context it was given, not the live repository. It can decide, research, critique, and correct at a high level over that materialised context, but it has no direct authority to inspect private files, execute commands, edit, test, or commit; any such action has to be carried out by an actor that does hold that access. The counterpart shape, Type A, is the actor running inside the live machinery with those affordances.

ScopeType B appears wherever the site describes work that happens outside the running repository: external reasoning lanes, provider and web calls, operator-carried questions, and bridge or injected-context exchanges. It is paired throughout with Type A, the in-harness actor.

ExampleA general assistant in a chat or browser window, asked a framing or research question and given a pasted block of context to work from, is acting as a Type B actor: it reasons over what it was shown and returns an answer, without reaching into the live repository itself.See it live: With a coding agentsee where an external agent works over handed-in context rather than the live repository

Not thisA Type B is not a lower intelligence tier and not simply any delegated worker. An agent that has direct, live access to the repository's files and commands is Type A, even when it has been delegated a task.

Reader ruleWhen something is produced by Type B, treat it as advisory: a synthesis built from the context it was shown, to be checked against the live system before anything is acted on.

Also shown astype_b, type-b

Search handlesexternal cognition lane, operator HUD, operator-hud type b, chatgpt web, bridge actor

Generated from the governed public vocabulary for Plectis.

bounded workers populate rows This is how the system keeps its many surfaces current at scale. Once a kind of thing has a known shape, with a defined target, input, output schema, validation command, and a record of what it is allowed to claim, Type B work carries out the repeatable part: refreshing an index, refilling a summary band, detecting duplicates, checking that evidence pointers still resolve, or applying a draft patch to a row. Each run is bounded by a fixed input and a fixed output shape, is checked against a stated standard, and can be safely re-run without changing the result.

ScopeThe term covers the system's maintenance and population runtime: sync, projection refresh, compression-band filling, duplicate detection, evidence-pointer checks, and draft row patches. A reader meets it wherever the architecture or a paper module explains how surfaces are generated and kept up to date.

ExampleThe Engine Room Metabolism Runtime is a concrete instance: the part of the system that runs these bounded, repeatable upkeep jobs and keeps the generated surfaces refreshed against their declared standards.See it live: Engine Room Metabolism Runtimeopen the paper module describing this upkeep runtime

Not thisType B metabolism is not the creative work of designing how a thing should be structured in the first place, and it is not the moment a result is finally approved or made public. It is the bounded, validated, repeatable work that runs once the shape is already known.

Reader ruleWhen a surface is described as produced by Type B metabolism, treat it as maintenance against a settled shape: it is kept current by repeatable, validated jobs, and it stops short of inventing new structure or making a final promotion decision on its own.

Also shown astype_b_metabolism, Type-B metabolism

Search handlesbounded metabolism, deterministic metabolism, worker metabolism, population metabolism

Generated from the governed public vocabulary for Plectis.

move learning upward Up-propagation is the direction in which reusable learning travels through the system: from a specific local case toward a more lasting home such as a skill, a standard, a paper module, an agent seed, or an axiom. The destination is chosen by how settled and how authoritative the lesson is, so a routine procedure lands in a skill, a fixed data shape lands in a standard, and operator intent lands in the source voice records. The aim is to record the lesson once, in the least authoritative place that can hold it honestly, rather than letting it be rediscovered.

ScopeThe term covers the upward movement of learning across the system's layers, from local tasks and signals up to skills, standards, paper modules, seeds, and axioms. A reader meets it in the doctrine and rules pages, particularly around the axiom on provenance propagation, and wherever the system explains how a local case improved a shared artifact.

ExampleThe axiom on provenance propagation and non-interference, AX-8, is a concrete instance: it states how a local lesson may be carried into a higher artifact while preserving where it came from and without disturbing the artifact it joins.See it live: Provenance propagation and non-interferenceopen the axiom that governs carrying a local lesson upward

Not thisUp-propagation is not a promotion of every observation into formal doctrine, and it is not a one-way push that overwrites the artifact it joins. It is the routing of a single local lesson into the most modest durable layer that can hold it.

Reader ruleWhen something is described as up-propagated, treat it as a local finding that has been deliberately lifted into a more durable artifact; trace it to that artifact to see where it now lives and what scope it claims.

Also shown asuppropagate, up propagate

Search handlesup propagation, uppropagation

Generated from the governed public vocabulary for Plectis.

one bounded execution pass Work in this system is organised into phases, and each phase is carried out as a sequence of waves rather than one continuously rewritten effort. A wave plans a single pass, runs it, records what it did and what the evidence showed, and then either evolves the working state or hands off cleanly. Because each wave has a defined boundary, the work stays resumable: a later pass can pick up from the recorded outcome instead of from chat history.

ScopeThe term covers the runtime unit of phase work and the lifecycle of planning, executing, recording, and assimilating one pass. A reader meets it wherever the site describes how a phase progresses, how execution continues across passes, and how outcomes are kept as durable records.

ExampleThe Bridge Phase Continuity Runtime is a concrete place waves appear: it carries execution across passes within a phase so that one wave's outcome can be resumed by the next rather than lost.See it live: Bridge Phase Continuity Runtimeopen the component that carries waves across passes within a phase

Not thisA wave is not a whole phase, a project milestone, or a vague burst of activity. It is one bounded execution pass with a defined objective, allowed paths, and a recorded outcome.

Reader ruleTake a wave as one finished pass of work with its own objective and recorded outcome, not the whole phase. What it changed and what it proved sit inside that one pass.

Also shown asexecution wave, phase wave, bounded wave

Generated from the governed public vocabulary for Plectis.

safe useful self-knowledge Workingness asks a sharper question than "do the tests pass". It is the diagnostic condition in which the system can turn evidence into calibrated belief, send each failure to the part of the system that owns its repair, and act only within bounds it is explicitly allowed to. It separates whether events were observed from whether the system's own state of belief is sound, and it is read off concrete signals such as a court pass, a drift check, or a live receipt before any change is made.

ScopeWorkingness covers the system's epistemic health as a whole, distinct from ordinary event logging. A reader meets it wherever a result is being interpreted before a change is made: an evidence page showing what a pass proves, a drift check, or a live receipt. The owning module is the Workingness Instrument, and any dossier is a readable projection of that state.

ExampleThe evidence page, "What the pass proves", is a concrete instance: it lays out exactly what a given pass does and does not establish, which is the workingness question made visible for one result.See it live: What the pass proves (evidence)see what a single pass actually establishes

Not thisWorkingness is not a green test suite or a build-passing badge. A run can be entirely green and still have low workingness if the system cannot say what remains unknown, what would change its mind, or which actions it is allowed to take.

Reader ruleTreat a workingness reading as a statement about the system's self-knowledge at that moment, not a warranty that everything is correct. Check what it is actually grounded in before relying on it to permit a change.

Also shown asworking, actually working, system workingness

Search handlesworkingness state, workingness dossier

Generated from the governed public vocabulary for Plectis.

truth-state action boundary It is the row-shaped contract for one live outcome. In one place it pins down the kind of claim, its current status, the evidence and dependencies under it, the conditions that would invalidate it, the appeals that block it from being promoted, and the repairs and mutations it allows or forbids. It turns judgments that would otherwise stay implicit into explicit fields: this receipt counts as evidence, this scorer output is a judgment, this projection is stale, this change is forbidden until a named gate passes.

ScopeThe term covers the governing record that binds evidence, judgment, appeals, repairs, and mutation permissions for a single live claim. A reader meets it where the site shows how a passing or failing result is allowed to act on the system, and a summary dossier may stand in front of it.

ExampleThe Proof Diagnostic Evidence Spine is a concrete instance: it links a specific result to the evidence under it and to what that evidence is permitted to claim, which is exactly the evidence-to-action binding a workingness instrument records.See it live: Proof Diagnostic Evidence Spineopen one component that binds evidence to what it may claim

Not thisA workingness instrument is not a verdict that the whole system is working, and not a tool that edits the system on its own. It is the record of what one result permits, with no power to change doctrine, routes, or standards by itself.

Reader ruleRead a workingness instrument as the boundary on what a result lets you do: its allowed and blocked actions are the operative part, not the surrounding summary.

Also shown asworkingness_instrument, workingness dossier

Search handlessystem workingness instrument, truth-maintaining instrument

Generated from the governed public vocabulary for Plectis.