Learn the language a Masscode project is written in.
Masscode writes every project as one graph: why it exists, what it must do, what was decided, which rules follow, what was built and what proves it. This course teaches that graph from the ground up, with the same vocabulary the verifier uses.
From a file to a verdict
You write the first box. Everything after it is done by programs, with no model anywhere.
The modules
Each module has something to click and a short check. A module counts as done when you answer its check. Your progress stays in this browser.
Every fact is a small statement.
A statement has a subject, a relationship and an object. The standard name for it is a triple. Each one is true or false on its own, so a program can check it without reading any prose.
Read a node as triples
A graph file groups statements by subject. Click a line to see the triples it writes.
The same facts in Turtle, the standard text format for this kind of graph. You never have to write it, but reading it once shows what the file means.
Why statements
- A statement is small enough to check on its own, and to trace to who wrote it.
- Two facts about the same thing never conflict silently: the vocabulary says how many values a property may have.
- The language is closed. A key the vocabulary does not know is an error, never an extension.
Three families, one status each.
Every element belongs to one family, which gives it its colour. Every element also carries one status, which changes its form, so the state of a project reads at a glance even without colour.
Status changes the form
A yellow ring waits for a person or is waived. A red ring failed or escalated. A faded card is still to come. A dashed card is proposed or unknown.
Twelve layers, from why to proof.
The graph is drawn in layers that follow the life of a project. Each layer only points back at layers that already exist, so every piece of code can be traced up to the reason it exists.
Explore the kinds of element
Pick a layer to see every kind of element it holds, its id prefix, and which conversation or program creates it.
Links you can read as sentences.
Every link reads as a sentence in both directions. "D-12 produces R-07" also says "R-07 was produced by D-12". Each link runs from certain kinds of element to certain others, and the verifier holds you to it.
Read a link
Build a statement
Choose a subject, a link and an object. The check uses the link's allowed kinds, the same way the generated shapes do.
Decisions become rules.
A decision in Masscode is more than a record. It names the drivers it answers, the options it rejected and the assumptions it rests on, and it produces at least one rule a checker can run. This is what makes a decision enforceable on the code.
Anatomy of a decision and its rule
From the Masscode project itself. Click a highlighted line.
Where each kind of rule is checked
A rule records its kind, when it applies and whether a machine checks it. Pick a kind.
Try rule MG-01
Every settled decision produces at least one rule, or states why nothing about it is enforceable. Without this, decision records become decoration.
Concerns that cross every layer.
Personal data, security controls and audit duties are not kept as lists by hand. Derivation rules carry them across the graph: from the data to its store, from the store to what connects to it, from a control to everything it governs, and from there to every task that touches it.
Watch derivation run
Nobody wrote that the database holds personal data, that the API handles it, or that task T-812 must meet the encryption control. Step through the rules on the Play Your Own Book sample.
Why derivation, and why it always stops
- A control names the classifications that bring it into scope, never a list of elements. When an element changes, its obligations change with it.
- Rules only add facts. They never remove one, so the loop settles after at most three rounds.
- Derived facts can never be written by hand. Writing one in a graph file is an error.
Where a fact comes from.
Every fact records how it was produced. Three of the four origins can gate work. The fourth, a fact an agent interpreted, stays inert until a person or a deterministic program backs it.
Can this fact gate a merge?
An agent proposed that the share service reads personal data (CF-readShared-pii). Change what backs it.
Draft and approved layers
What the current step produces lives in the draft layer. Rules run over both layers together. At the gate, the draft is promoted in one step, recorded with the name of the person who approved it.
Draft
Approved
Five lanes, no model anywhere.
The verifier reads the graph in five lanes. Every finding has the same shape whatever lane raised it: the lane, the rule, the severity, the element and a plain sentence. The verdict is fail when there is a violation, unknown when a rule could not decide, and pass otherwise.
Run the verifier on the sample
The Play Your Own Book sample, as first written, before its corrections.
The rulebook
| Id | Rule | What it requires | Severity |
|---|
A small core on open standards.
Masscode owns fewer than forty classes and borrows the rest from standards that other people maintain and auditors already recognise. The link is always thin: a Masscode class is declared a special case of a standard class, never its equivalent, so a mistake in another standard is never imported.
Climb the hierarchy
A tool that only knows the standard can still read Masscode facts. Pick a class or a link.
Why the checker works in a closed world
The same missing fact, read by an ontology reasoner and by shapes. Compliance needs the second reading.
When the project changes.
Nothing in the graph is overwritten. New facts arrive in delta files that can only add. A wrong decision is replaced by a new one that points back at it, and a decision reopens by itself when a measurement crosses one of its assumptions.
The life of decision D-05
A real thread from the Masscode project building itself. Click a moment.
Promises, then proofs
Definition time writes a promise: "TT-812 proves AC-4.2". Implementation time writes the proof: "EX-90 executed TT-812 on commit b204, and it passed". The same rule reads both. These implementation facts arrive from the code host, the model proxy, the sandbox and the orchestrator, never from a model's word.
Every kind and every link.
The whole vocabulary on one page, from the same data as the modules.