sxsphinxstack

Home / Graph

What a graph does to a skill

A skill file records a procedure: the steps, the rules, and what done means. It deliberately says nothing about where it sits. This page is about what happens when you give it that context. A graph changes what a skill means, makes properties of it measurable that no amount of reading can reveal, and introduces costs that lone files never pay. The evidence comes from two live corpora that share one file format and made opposite choices.

A skill by itself

This library holds 1,021 skills as standalone markdown files. Each one states when to use it, the steps in order, the rules that must hold, and what must be true at the end. The file is context-free on purpose: it loads into any agent, travels between projects, and survives a change of tools, because nothing in it refers to anything outside it.

That portability has a price. The file cannot say who should run the work, what upstream work feeds it, where its output goes, or how the surrounding operation judges the result. A skill's Use when line gives a trigger, and a trigger answers only the question of when. Who, from what, and for what happens next are questions a lone file cannot hold.

A skill in a graph

The sister project smbwiki made the other choice. It models 125 business types as one graph in which each skill is a shared node, and each business that runs the skill binds it: which roles own it, which records go in and out, which metric judges it, which software category runs it. The skill's process text is a single file. Its meaning is assembled per business, from the edges.

Machine shop Pizzeria Law firm Accounts payable owner: office manager records: supplier invoice, payment record
Accounts payable as one node with many parents. Each business supplies its own binding: the owner, the records, the judging metric. The process text is identical in all of them.

Situation

The first thing the graph adds is an address. The file says how the work is done. The edges say who owns it in this operation, which record arrives to start it, which record it must produce, and which number the operation watches to judge it. An agent holding the lone file can perform the procedure. An agent holding the neighborhood also knows what to ask for before starting and where the result is supposed to go, which is most of the difference between completing a task and participating in an operation.

Generality becomes a measurement

Read accounts payable and try to determine from the text whether it is universal or niche. You cannot. The prose of a general skill and the prose of a specialist skill look the same. The graph answers the question empirically: accounts payable runs in 108 of smbwiki's 125 business types, while 173 of its 227 skills run in exactly one. Generality turns out to be a property the corpus assigns to the skill, visible as the node's in-degree, and invisible in the file. The distribution has a characteristic shape: a small spine of back-office skills nearly every operation shares, and a long tail of trade work that identifies a single business. Any sufficiently large skill library almost certainly has the same shape. Without a graph over it, nobody can see it.

Identity moves into the wiring

The strongest measurement on smbwiki is this one: 88 of its 125 business types run no skill that some other type does not also run. Their entire skill set is shared parts. What makes a caterer different from a pizzeria is which skills are present together and how records pass between them: quoting produces the quote that invoicing consumes, invoicing produces the customer invoice that accounts receivable chases, and the chain of documents is the actual structure of the operation. A business relates to its skills the way a product relates to its parts, and the parts are mostly standard. The other sister project, BOMwiki, makes the identical argument for hardware: the same ball bearing appears in an espresso machine and an excavator, and the product's identity lives in the assembly.

Quoting Invoicing Accounts receivable quote customer invoice
Documents are the wiring. One skill's output record is the next skill's input, and the flow of records is the dependency structure of the business.

Claims become checkable

A lone file can name any record, any role, and any measure, and nothing pushes back. In a graph, every name a skill uses must resolve to a node that exists, and smbwiki's build fails on a single broken reference. This gate is narrower than it sounds and stronger than it sounds at the same time. It cannot judge whether the procedure is wise. What it can do is force every noun in a thousand-file corpus to be a real, shared, inspectable thing, and that is the precondition for any deeper form of checking. The machinery is documented at how the graph is built.

Corrections travel

When 108 businesses each keep their own copy of a procedure, the copies diverge one small edit at a time, and no one notices until two of them disagree in front of a customer. When they share a node, one correction lands on every page that uses it, immediately. The same property is the graph's largest cost: an edit to a shared node touches 108 operations at once, so a shared corpus needs review machinery, stable identifiers, and a tolerance for slower editing that a folder of lone files never demands. Portability and shared structure trade off against each other, and the two corpora simply picked different points: this library keeps skills portable and pays by carrying no situation; smbwiki situates skills and pays in curation. Because both use the same plain-text format, a skill can cross between them, and what survives the crossing is the process text.

Open questions

These are the questions this pair of corpora makes askable, in roughly the order they could be answered.

Where to look