cosmoes.org

macro.cosmoes.org · specification · v0.0.2 · one line per section

MacroCOSM OES

MacroCOSM OES is the shared grammar every MiniCOSM is written in

Outline

  1. Contents — every section of this specification, in order
  2. How to read this — the rule words, the words on screen, and what an example promises
  3. 1 Provenance and the name — where MacroCOSM came from, what its name means, and who keeps it
  4. 1.1 Lineage — MacroCOSM did not start as a grammar
  5. 1.2 The name — COSM is the family's name
  6. 1.3 Stewardship — MacroCOSM is stewarded by Verroes (Graham Smith)
  7. 2 The model on one page — a volume read as a file system and as a relational database
  8. 3 Scales: MacroCOSM, MiniCOSM, MicroCOSM — the three scales: the grammar, a domain's dialect, an organization's additions
  9. 4 The file format — how a cosm file is written: its encoding, its YAML subset, its scalars
  10. 4.1 Encoding and shape — A .cosm file is UTF-8, with or without a byte-order mark
  11. 4.2 The COSM YAML subset — The subset is YAML without the parts that make a file mean something other than…
  12. 4.3 Scalars — Booleans are YAML 1.2's: true and false, in lower, title or upper case
  13. 4.4 Comments and style — Comments are YAML's #
  14. 4.5 Writing — A writer dumps with yaml.safe_dump(data, sort_keys=False, allow_unicode=True, width=110)
  15. 4.6 Text, not code — A .cosm file is data
  16. 5 The declaration — the one line that names a volume's MiniCOSM, and what a reader refuses
  17. 5.1 The form — A catalog says which MiniCOSM it is written in with its first key
  18. 5.2 Identifying a catalog — The reader keeps a registry of the manifests it knows
  19. 5.3 Refusal — A refused catalog loads nothing
  20. 5.4 Legacy forms — A legacy key is never an error
  21. 5.5 Writing the declaration — A writer creating a volume writes the declaration as the first key of its catalog
  22. 5.6 The reserved key macrocosm: — A catalog or a manifest may carry macrocosm: 0.0.2
  23. 6 Volumes and catalogs — a volume is one database, headed by its catalog
  24. 6.1 Volumes — A volume is one database of a MiniCOSM
  25. 6.2 The catalog — The catalog is the file at the root of a volume that declares the MiniCOSM…
  26. 6.3 The volume block — The manifest's volume block says where the files of a volume are
  27. 6.4 Parts — A MiniCOSM may divide a folder volume into top-level parts, each with its own modules
  28. 6.5 Module files — In a folder volume, a module file is a .cosm file in the places…
  29. 6.6 What is never in a file — A MiniCOSM may keep some of what it describes out of its files on purpose
  30. 7 Items, kinds, fields — items, the modules and kinds they belong to, and their fields
  31. 7.1 Items — An item is a row: a mapping with a string id and a type
  32. 7.2 Modules — A module is a group of kinds: a group of tables
  33. 7.3 Kinds — A kind is a table
  34. 7.4 Fields — A field is a column
  35. 8 The envelope — the columns every item carries, whatever its kind
  36. 8.1 The columns every item has — The envelope is the set of columns every item carries, whatever its kind
  37. 8.2 Required fields — A MiniCOSM declares which envelope fields every item must carry, in its manifest's envelope.required
  38. 8.3 Envelope fields a MiniCOSM adds — A MiniCOSM may add fields to its envelope
  39. 8.4 Status and visibility — Unless a manifest gives other lists, the closed lists are Comprise's
  40. 8.5 Provenance — Sources or it didn't happen
  41. 8.6 Unknown fields — Allowed, and kept
  42. 9 References and links — how one item points at another, and how a reader resolves it
  43. 9.1 What a reference is — A reference is an id written in a reference field: a foreign key
  44. 9.2 Two ends — A reference that names nothing in the volume fails the check ref-unresolved, an error
  45. 9.3 Resolution — A bare id resolves in its own part; a qualified id in the named part
  46. 9.4 Typed links — A typed link is a mapping {rel: <word>, to: <id>} in an item's links: list
  47. 9.5 Relations are fields — There is no syntax for a relation other than a field that holds an id
  48. 9.6 Wildcard fields and literals — In a wildcard reference field (roles.*), a value is checked as a reference only when…
  49. 10 Open questions — an unknown written down as a question, never as a guess
  50. 11 Ids, paths, URIs — how anything is addressed: an item's id, its path and its URI
  51. 11.1 Ids — The manifest may declare other forms
  52. 11.2 Paths — A path is an id respelled as a location
  53. 11.3 URIs — For use outside one volume, a path is qualified with the MiniCOSM and the volume's…
  54. 12 Checks — the checks every volume can be held to, and the report they make
  55. 12.1 What the checks are — The checks (lint) are the constraints of the database, run over the whole volume
  56. 12.2 The generic checks — The generic checks, in Checks
  57. 12.3 Which checks run — load always runs
  58. 12.4 The report — ok is the verdict the generic checks give
  59. 12.5 Checks and writes — A MiniCOSM may say that every write goes through its checks and that a write…
  60. 12.6 What the generic checks do not verify — What a domain means
  61. 13 The manifest — the small file that declares a MiniCOSM, so a reader needs no new code
  62. 13.1 What it is — A manifest is the machine-readable declaration of a MiniCOSM
  63. 13.2 Its format — A manifest is written in the COSM YAML subset and starts with its own declaration
  64. 13.3 The keys — These are the keys of Comprise's manifest, read generically, with the 0.0.1 additions marked
  65. 13.4 Read generically — A generic reader needs only the keys above to load, check and draw a volume
  66. 13.5 What 0.0.1 adds — Optional keys new in 0.0.1
  67. 13.6 The registry — A reader loads every *.manifest.cosm in its manifest folders into a registry
  68. 14 Renderers and lenses — how a volume is drawn: renderers, the text tree and Mermaid lenses
  69. 14.1 Renderers — A renderer turns a volume into another form
  70. 14.2 The text tree — to_text_tree(volume) writes the volume as indented text: the catalog's declaration, id and name
  71. 14.3 Lenses — A lens is a Mermaid rendering of a volume from one angle
  72. 14.4 How the generic renderer draws — to_mermaid(volume, lens) returns the Mermaid text and a node_map
  73. 14.5 Lenses that ship — In the reader's order, a volume has these lenses: a Holotype, map and tree
  74. 15 Versions and signatures (by reference) — saved versions and signatures, defined in Comprise OES 1
  75. 16 The private/public split (by reference) — the private Holotype and its public isotype: two formats, not a setting
  76. 17 MicroCOSMs (mapped) — one organization's additions to a MiniCOSM, mapped and not yet built
  77. 18 The MiniCOSMs enough ships — the seven MiniCOSMs enough ships, one manifest each
  78. 18.1 comprise: Comprise OES 1 — a company as Comprise describes it, read here without Comprise's own rules
  79. 18.2 cosm: the standalone product tree — one whole's product tree, as COSM 0.2 and 0.3 wrote it
  80. 18.3 canon: the store's enumeration — a Canon volume or a project: its files and what was made from them
  81. 18.3.1 The catalog — The catalog, in canon: the store's enumeration
  82. 18.3.2 The module and its kinds — One module, V (Volume): what the volume holds
  83. 18.3.3 Ids — An item's id is V:<kind>/<slug>, and its slug is its path, respelled
  84. 18.3.4 The project catalog — A project gets a catalog too: rness/canon.cosm, with scope: project
  85. 18.3.5 Atems — An atem is the tightest fair, full, plain-English reduction of a text…
  86. 18.3.6 Examples — A Canon volume's catalog
  87. 18.4 emf: a text's enumeration — one text taken apart into what it says, item by item
  88. 18.4.1 The catalog — A twin is fresh while its text's size and modification time match the twin's source
  89. 18.4.2 The modules and their kinds — Required: id, type, name, summary, provenance
  90. 18.4.3 The conventions, in plain words — Every L:term says where its word stands in FEED, the dictionary enough ships: feed
  91. 18.4.4 Shorts — A short is a telling of a text that enough compiles from its EMF twin
  92. 18.4.5 An example — The text, guides/close.md in the Canon volume of section 18.3.6
  93. 18.5 doc: a document's enumeration — one document taken apart into items and compiled back, byte for byte
  94. 18.5.1 The catalog — The catalog, in doc: a document's enumeration
  95. 18.5.2 The modules and their kinds — Required: id, type, name, summary
  96. 18.5.3 The conventions, in plain words — atem is the one line the atem density shows: two to fifteen words
  97. 18.5.4 Its own checks — A generic reader lists these seven as not run
  98. 18.5.5 An example — The text, a small handbook in the spirit of section 18.4.5, handbook.md
  99. 18.6 ascribe: a person's holograph — one person described without a name, in ten kinds of node anchored to forms
  100. 18.7 thym: programs and what they leave — Thym's programs, morphs, contexts, plans, traces and packages, one file each
  101. 19 Conformance — what a conforming reader and writer must do, and the corpus that shows it
  102. 19.1 A reader must — A reader must, in Conformance
  103. 19.2 A writer must — A writer must, in Conformance
  104. 19.3 The conformance corpus — A reader conforms to MacroCOSM OES 0.0.1 when
  105. 19.4 Where the reader wins — No disagreement between this text and enough/macrocosm.py is known at the time of writing
  106. 20 Decisions in this version — the decisions this version settled, one numbered line each
  107. 21 Open questions and roadmap — what is mapped but not built, and what this version leaves open
  108. 21.1 Mapped, not built — MicroCOSMs (section 17)
  109. 21.2 Left open by this version — Whether a person's own manifests may precede the shipped ones in the registry
  110. Appendix: the mapping to Comprise OES 1 — Section by section, where each part of this document comes from in Comprise OES 1
  111. Colophon — MacroCOSM OES — Copyright © 2026 Graham Smith
  112. Comprise OES 1 — The code in core/ is the reference reader and writer
  113. Contents — Contents, in Comprise OES 1
  114. How to read this — The words a person reads on screen come first (they are MO.md's)
  115. 1 The map — A Holotype is a file system that is also a relational database
  116. 2 The volume — The volume: Layout, The catalog: holotype.cosm, The declaration: oes: comprise/1, Module files
  117. 2.1 Layout — A module folder's letter is read case-insensitively (p/ loads as P/)
  118. 2.2 The catalog: holotype.cosm — One YAML mapping
  119. 2.3 The declaration: oes: comprise/1 — A Holotype says which MiniCOSM it is written in with one line in its catalog
  120. 2.4 Module files — A module file is a .cosm file anywhere under atoms/<concern>/<letter>/, at any depth
  121. 2.5 Reading a file — UTF-8, with or without a byte-order mark; CRLF and LF read the same
  122. 2.6 E: people are never in a file — atoms/<concern>/E/ holds a README saying where the people are, or a none.cosm with module
  123. 2.7 Other folders — vendors/ (3.5) and snapshots/ (10) are read-only to the app
  124. 2.8 The local database — store.sqlite, one per Holotype
  125. 3 Concerns and relationships — Concerns and relationships: Concerns (atoms), Relationships (bonds), Outside organizations (stubs), Groups
  126. 3.1 Concerns (atoms) — A concern is one bounded whole, described on its own
  127. 3.2 Relationships (bonds) — A relationship is a typed, dated, sourced tie between two concerns
  128. 3.3 Outside organizations (stubs) — An outside organization is one the Holotype names but does not model
  129. 3.4 Groups — A group (atom group) is a named set of concerns
  130. 3.5 Vendor-published atoms — A vendor may publish one of its concerns at https://<domain>/.well-known/comprise/<slug>/
  131. 4 The envelope — Every item carries the same envelope: the system columns of every table
  132. 4.1 P is different — Items in P (chapter P) carry COSM's identity instead
  133. 4.2 Visibility — A hidden item is absent, not refused
  134. 4.3 Provenance — Sources or it didn't happen, in Comprise OES 1
  135. 5 The eight modules — Every concern has the eight modules, C · O · M · P · R…
  136. Chapter C · Corporation — The legal body: ownership, contracts, filings, money
  137. Chapter O · Organizations — Roles, teams, seats and who decides
  138. Chapter M · Markets — Chapter M · Markets, in The eight modules
  139. Chapter P · Products: the product tree — What it offers, and why that matters
  140. P.1 What P describes — P describes what a concern offers as a tree under its brand
  141. P.2 Levels (strata) — Five levels
  142. P.3 The nine questions (aspects) — Every item answers nine questions
  143. P.3.1 identity — identity, in The nine questions (aspects)
  144. P.3.2 flow — flow, in The nine questions (aspects)
  145. P.3.3 substrate — substrate, in The nine questions (aspects)
  146. P.3.4 rules — A rule is written as "<actor> <aim> <object>" under must, may or must-not
  147. P.3.5 principles — principles, in The nine questions (aspects)
  148. P.3.6 economics — Every offering has a price, none, or an open question (rule 3)
  149. P.3.7 vocabulary — vocabulary, in The nine questions (aspects)
  150. P.3.8 affect — Offerings must declare affect; other items may
  151. P.3.9 mattering — The aspect the rest exist for
  152. P.4 Roles, not people — People never appear in P
  153. P.5 Relations and inheritance — Relations and inheritance: Relations, Externals, Inheritance
  154. P.5.1 Relations — Six relations
  155. P.5.2 Externals — In a Holotype, P declares no externals of its own
  156. P.5.3 Inheritance — Three aspects flow down the tree; six do not
  157. P.6 The sketch (shorthand) — For whiteboards, interviews and chat
  158. P.7 The files of P — cosm: 0.3 heads each file
  159. P.8 Drawings — Every drawing is a view over the same items, never drawn by hand
  160. P.9 P's checks — Two levels
  161. P.10 How P renders for an audience — The internal rendering holds everything
  162. P.11 What COSM 0.3 described that Comprise OES 1 does not build — Kept as the map of where P can go
  163. P.12 Where COSM 0.3's text and the code disagree — The code wins in every row
  164. Chapter R · Representations and reflections — Chapter R · Representations and reflections, in The eight modules
  165. Chapter I · Inventories — SKUs a feed brings in live in the local database, not the files
  166. Chapter S · Stacks — Chapter S · Stacks, in The eight modules
  167. Chapter E · Employees — The people: counted here, never named
  168. 6 Paths — Every concern, module, kind, item and field has a path
  169. 6.1 Properties — A respelling
  170. 6.2 Grammar — A kind segment must be a kind of that module in the manifest
  171. 6.3 From an id to a path, and back — The module and kind levels have no id today; the path is their only name
  172. 6.4 Edge cases, settled — Edge cases, settled: P's brand item, Kinds that share a file, Relationships, Outside organizations
  173. 6.4.1 P's brand item — The brand's id has no kind: P:<slug>
  174. 6.4.2 Kinds that share a file — The kind level is a table, not a file
  175. 6.4.3 Relationships — A relationship between two concerns is written in both (3.2), with one id
  176. 6.4.4 Outside organizations — An outside organization is an ordinary item of C: mozilla-corporation/C/counterparty/google
  177. 6.4.5 Vendor-published atoms — A vendor-published atom's path is its id, vendor/<domain>/<slug>, and nothing below it
  178. 6.4.6 Fields — The field path is the one the checks already write for open questions
  179. 6.4.7 The qualified form — For use outside one install, a path is qualified with the MiniCOSM and the Holotype
  180. 6.4.8 Case, characters and what has no path — Ids and paths are case-sensitive and keep their case: meadow/O/role/Founder
  181. 6.5 Where paths are accepted — Beside ids, never instead of them
  182. 6.6 Scope and safety — A path to something the reader may not see answers exactly as its id would
  183. 6.7 Examples — Every example in this document resolves on the fixtures
  184. 7 References — A reference is an id written in a field: a foreign key
  185. 7.1 Forms — An item's own id is written bare in its concern's files
  186. 7.2 Where references are checked — The envelope's reference fields (section 4) and each kind's reference fields
  187. 7.3 Resolution — A bare id resolves in its own concern's module
  188. 7.4 Scope — A reference to an item the reader may not see stays as the id…
  189. 7.5 Named relations — plan/comprise-model.md names the cross-module relations (owner, holds, serves, sold-through, priced-by, maps-to or entitles, listed-on, runs-on…
  190. 8 Open questions — An open question (pending) is a value nobody has yet given
  191. 9 Checks — The checks (lint) are the constraints of the database, run on the whole Holotype
  192. 9.1 What runs — What runs, in Checks
  193. 9.2 The envelope's checks — The envelope's checks, in Checks
  194. 9.3 The fourteen rules — Each rule reports one of: pass, fail, unverifiable, finding
  195. 9.4 The verdict — ok: no error and no failed rule
  196. 10 Versions — A saved version (snapshot) is an immutable copy of the model files at a moment
  197. 11 The private/public split — Two formats, not one format with a setting
  198. 11.1 The private side — The files stay on the subject's machine
  199. 11.2 Renderings for an audience — Renderings for an audience, in The private/public split
  200. 11.3 The isotype: a view, default-deny — The isotype (comprise-isotype/0) is a separate document with a fixed schema
  201. 12 Renderers — A renderer turns a Holotype into another form
  202. 13 Conformance — Conformance: A reader must, A writer must, What the checks verify
  203. 13.1 A reader must — A reader must, in Conformance, in Comprise OES 1
  204. 13.2 A writer must — A writer must, in Conformance, in Comprise OES 1
  205. 13.3 What the checks verify, and what they do not — the load, the oes: declaration included (2.3); the id grammar; kinds per module
  206. 13.4 Where the code wins — Besides chapter P.12
  207. 14 Decisions in this version — Made by the writer of slice 30b, 2026-10-20, without asking, as the brief required
  208. OES: the paradigm map
  209. The short version — Comprise describes a company as a file system that is also a relational database
  210. 1 What an OES is — An OES, an organizational enumeration system, is a system that organizes a domain by enumerating…
  211. 2 Three scales — COSM is the family's name
  212. 3 What MacroCOSM gives every MiniCOSM — The shared grammar
  213. 4 What a MiniCOSM declares — A MiniCOSM is declared by its manifest: one .cosm file, outside every database, that says
  214. 5 What a MicroCOSM may change — A MicroCOSM is one organization's extension of a MiniCOSM
  215. 6 Where Comprise OES sits — Comprise OES is the first MiniCOSM, and the one MacroCOSM is being read out of
  216. 7 Connections to the wider ecosystem — None of this is built
  217. 8 The picture — The picture, in OES: the paradigm map
  218. 9 What is built today — What is built today, in OES: the paradigm map
  219. 10 In this folder — In this folder, in OES: the paradigm map

Glossary

as told
every item where its span puts it, in the author's order: told in the files — defined in §18.4.4 Shorts
atem
the tightest fair, full, plain-English reduction of a text or of a passage of one — defined in §18.3.5 Atems
by weight
the claims that matter most first, then the events, then the terms — defined in §18.4.4 Shorts
Canon
Canon is enough's library — defined in §18.3 canon: the store's enumeration
catalog
the file at the root of a volume that declares the MiniCOSM and says what… — defined in §6.2 The catalog
chapter
A chapter is a document synced into the volume, read-only, in its author's own words — defined in §18.5.3 The conventions, in plain words
checks
the constraints of the database, run over the whole volume — defined in §12.1 What the checks are
COSM
the family's name — defined in §1.2 The name
DocOES
DocOES, Documentation OES, takes a markdown document apart into items — defined in §18.5 doc: a document's enumeration
EMF
EMF stands for enumerated meaning fabula: the fabula of a text, enumerated — defined in §18.4 emf: a text's enumeration
envelope
the set of columns every item carries, whatever its kind — defined in §8.1 The columns every item has
fabula
A text's fabula is the order-free material a telling is made from — defined in §18.4 emf: a text's enumeration
field
a column — defined in §7.4 Fields
focus
at most two sentences — defined in §18.3.5 Atems
Holotype
the complete, private description of one subject, kept by the subject, on the subject's machine — defined in §16 The private/public split (by reference)
isotype
a small public projection of the Holotype — defined in §16 The private/public split (by reference)
item
a row: a mapping with a string id and a type — defined in §7.1 Items
Its envelope
Comprise's, so that the same moves work on both subjects — defined in §18.6 ascribe: a person's holograph
kind
a table — defined in §7.3 Kinds
lens
a Mermaid rendering of a volume from one angle, declared in the manifest — defined in §14.3 Lenses
MacroCOSM
the whole language: the shared grammar every MiniCOSM is written in — defined in §3 Scales: MacroCOSM, MiniCOSM, MicroCOSM
manifest
the machine-readable declaration of a MiniCOSM — defined in §13.1 What it is
MicroCOSM
one organization's extension on top of a MiniCOSM — defined in §3 Scales: MacroCOSM, MiniCOSM, MicroCOSM
MiniCOSM
an OES for one domain, declared by a manifest — defined in §3 Scales: MacroCOSM, MiniCOSM, MicroCOSM
module
a group of kinds: a group of tables — defined in §7.2 Modules
OES
stands for organizational enumeration system — defined in §1.2 The name
open question
a value nobody has yet given, written where the value would go — defined in §10 Open questions
part
a top-level division of a volume (Comprise: concern, atom) — defined in How to read this
pull
one sentence: what the reader should actually take away — defined in §18.3.5 Atems
push
one sentence: what the author wants the reader to take away, believe or do — defined in §18.3.5 Atems
reference
an id written in a reference field: a foreign key — defined in §9.1 What a reference is
renderer
turns a volume into another form — defined in §14.1 Renderers
salience
A claim's salience is how much it matters to the text — defined in §18.4.3 The conventions, in plain words
short
A short is a telling of a text that enough compiles from its EMF twin — defined in §18.4.4 Shorts
span
An item's span points it back at the text — defined in §18.4.3 The conventions, in plain words
stance
A claim's stance is how the text knows it — defined in §18.4.3 The conventions, in plain words
syuzhet
A syuzhet is a telling of a fabula, an arrangement of its material — defined in §18.4.4 Shorts
telling
A telling is one arrangement of a fabula in words — defined in §18.5.3 The conventions, in plain words
the line
one sentence of 15 to 25 words that says what the whole says — defined in §18.3.5 Atems
a mapping {rel: <word>, to: <id>} in an item's links: list — defined in §9.4 Typed links
volume
one database of a MiniCOSM — defined in §6.1 Volumes

Comprise OES 1's terms

ATTEST: allowed
ok, and no rule unverifiable — defined in §9.4 The verdict
checks
lint, equilibrium rules — defined in How to read this
concern
one bounded whole, described on its own — defined in §3.1 Concerns (atoms)
export for agents
export for agents, called pack in the files — defined in How to read this
group
a named set of concerns ("the group", a reporting segment), declared in the catalog's groups — defined in §3.4 Groups
item
item, called node in the files — defined in How to read this
kind
kind, called type in the files — defined in How to read this
ok
no error and no failed rule — defined in §9.4 The verdict
open question
a value nobody has yet given, in Comprise OES 1 — defined in §8 Open questions
outside organization
one the Holotype names but does not model — defined in §3.3 Outside organizations (stubs)
relationship
a typed, dated, sourced tie between two concerns — defined in §3.2 Relationships (bonds)
renderer
turns a Holotype into another form — defined in §12 Renderers
saved version, signed version
saved version, signed version, called snapshot, attestation in the files — defined in How to read this
the local database
the local database, called store in the files — defined in How to read this

OES: the paradigm map's terms

Checks
constraints on the whole database, run on every write — defined in §3 What MacroCOSM gives every MiniCOSM
COSM
the family's name, in OES: the paradigm map — defined in §2 Three scales
Items, fields and references
an item is a row with a stable id and a kind — defined in §3 What MacroCOSM gives every MiniCOSM
MacroCOSM
the whole language, in OES: the paradigm map — defined in §2 Three scales
MicroCOSM
one organization's extension on top of a MiniCOSM, in OES: the paradigm map — defined in §2 Three scales
MiniCOSM
an OES for one domain, declared by a manifest, in OES: the paradigm map — defined in §2 Three scales
Open questions
a value nobody has given yet, written where the value would go — defined in §3 What MacroCOSM gives every MiniCOSM
Paths, and a URI form
every top-level part (a concern, in Comprise OES), module, kind — defined in §3 What MacroCOSM gives every MiniCOSM
Renderers
anything that turns the database into another form — defined in §3 What MacroCOSM gives every MiniCOSM
Saved and signed versions
an immutable copy of the files at a moment, with a manifest of hashes — defined in §3 What MacroCOSM gives every MiniCOSM
The envelope
the columns every item has, whatever its kind: owner — defined in §3 What MacroCOSM gives every MiniCOSM
The manifest
the machine-readable declaration of a MiniCOSM — defined in §3 What MacroCOSM gives every MiniCOSM
The private/public split
two formats, not one with a setting: the complete private description — defined in §3 What MacroCOSM gives every MiniCOSM

Reference

Comprise OES · comprise/1

a company: its concerns, their relationships, eight modules each

COSM product tree · cosm/0

one whole's product tree, outside any Holotype

Canon · canon/1

a Canon volume, or a project

  • V Volume — What the volume holds: folder, file, article
  • list status — the 4 values Canon allows for status
  • list visibility — the 3 values Canon allows for visibility
  • list twin.state — the 4 values Canon allows for twin.state
  • list emf.state — the 2 values Canon allows for emf.state
  • lens tree — the volume's folders, files and articles, joined by parent
  • lens map — every module, every reference field and typed link, parts and parent, in Canon

EMF · emf/1

one text: its words, the things and ideas it names, its claims, its events

  • L Lexicon — The words the text leans on: term
  • E Entities — The particular things and people named: person, org, place, work, thing
  • K Concepts — The ideas and universals the text uses: concept
  • P Propositions — What the text claims, and how it knows: claim
  • T Transitions — What happens, in order: event
  • X Atems — The tight reductions of passages: atem
  • list status — the 4 values EMF allows for status
  • list visibility — the 3 values EMF allows for visibility
  • list provenance.mode — the 12 values EMF allows for provenance.mode
  • list provenance.state — the 4 values EMF allows for provenance.state
  • list stance — the 6 values EMF allows for stance
  • list salience — the 4 values EMF allows for salience
  • list feed.origin — the 2 values EMF allows for feed.origin
  • list links.rel — the 9 values EMF allows for links.rel
  • lens claims — entities, concepts and claims, joined by role slots and typed links, coloured by stance
  • lens map — the text's lexicon, entities, concepts, claims and events as a mindmap

DocOES · doc/1

one document: its sections, terms, examples and decisions, joined to the reference

  • S Structure — What the document is made of: section, example, decision, chapter
  • T Terms — The words it defines: term
  • R Reference — What the manifests declare: minicosm, module, kind, list, check, lens
  • B Bubbles — The help that sits beside a control: bubble
  • list status — the 6 values DocOES allows for status
  • list visibility — the 3 values DocOES allows for visibility
  • list provenance.mode — the 12 values DocOES allows for provenance.mode
  • list provenance.state — the 4 values DocOES allows for provenance.state
  • list convention — the 5 values DocOES allows for convention
  • list links.rel — the 6 values DocOES allows for links.rel
  • lens manual — the readable manual: the document compiled as told, its short density
  • lens map — the document's sections and terms, as a mindmap
  • lens graph — what an item mentions, defines and exemplifies, and what mentions it
  • lens inventory — every item as one row: its id, kind, version, anchor and atem
  • lens tree — the document's sections, joined by parts and parent

Ascribe · ascribe/1

one person, without a name: the holograph, ten kinds of node anchored to forms

Thym · thym/1

Thym's programs, morphs, contexts, plans, traces and packages

  • P Programs — What a program says and does: program, move, step, contract
  • M Morphs — How a telling departs from the plainest one: morph
  • C Contexts — The occasion a text is told or read on: context
  • R Runs — What a program will do, and what a run did: plan, node, trace, record
  • K Packages — What a text travels in, and what was read from it: package, reading
  • list status — the 4 values Thym allows for status
  • list visibility — the 3 values Thym allows for visibility
  • list provenance.mode — the 12 values Thym allows for provenance.mode
  • list provenance.state — the 4 values Thym allows for provenance.state
  • list form — the 8 values Thym allows for form
  • list basis.* — the 2 values Thym allows for basis.*
  • list toward — the 2 values Thym allows for toward
  • list outcome — the 2 values Thym allows for outcome
  • list links.rel — the 5 values Thym allows for links.rel
  • lens program — the program as written, compiled back from its items: its short density
  • lens plan — a plan's nodes in the order they run, joined by what each runs after
  • lens trace — every record of a run as one row (a table, not a drawing)
  • lens map — the map lens of Thym

Checks

  • load — a file that does not parse, is not a mapping, or uses a forbidden construct (error)
  • duplicate-id — an id already loaded in the same module of the same part; the first wins (error)
  • id-grammar — an id that does not parse in the MiniCOSM's id form (error)
  • id-module — an id whose module the MiniCOSM does not declare, or, in a folder volume (error)
  • type — a missing type, or a kind the item's module does not declare (error)
  • type-prefix — an id whose kind disagrees with its type, outside the exception forms the manifest declares (error)
  • identity-min — a field the manifest's envelope.required lists that the item does not carry (error)
  • provenance — a provenance block missing where required, or malformed (error)
  • status — a status outside the status list (error)
  • visibility — a visibility outside the visibility list (error)
  • ref-grammar — a value in a named reference field that is not an id of a known… (error)
  • ref-unresolved — a reference that names nothing in the volume (error)
  • closed-list — a value outside its closed list, for any field the manifest's closed-lists names (error)
  • pending-shape — an open question whose question is empty or not a string (warning)
  • module-none — a module: none with no reason (warning)
  • catalog-key — a catalog key the manifest's catalog.keys does not list (a note) (error)
  • atem-shape — an item with no atem (error)
  • numbering — a section number used twice, one that skips or repeats among its siblings (error)
  • term-defined-once — a term the document defines more than once; the first definition is kept (warning)
  • unlinked-mentions — a paragraph that opens with a bold phrase the way a definition does (note)
  • empty-section — a heading with no body and no sections under it (note)
  • stale-provenance-hash — a generated item whose part of a manifest has changed (warning)
  • xref-unresolved — a reference across volumes that names nothing in its inventory (error)