Masscode Graph Language
Learn the Masscode graph language

Decisions the code has to keep.

The Masscode graph language is how a project is written down: every objective, requirement, decision, rule, task and proof as a small statement a program can check. Because decisions live in the same graph as the code's evidence, a decision is no longer a document. It is a promise the code is held to on every commit.

D-05:  a: mc:Decision  label: Where the fact graph lives  consumes: [NFR-1, NFR-3]  assumption: [Under 150 thousand facts]  produces: [R-07]R-07:  a: mc:Rule  label: Slice check under two seconds  phase: code  mechanical: true  governs: [T-109, CMP-validator]
MG-01D-05 produces a rule a program can runpass
Facts

Every line is a statement.

A subject, a relationship and an object, written in plain YAML and turned into standard RDF. Each one is true or false on its own, and each one knows who wrote it.

A closed vocabulary

Nothing is invented.

A small owned core, versioned like software and approved by a person. A key the vocabulary does not know is an error, and a new term enters as proposed until someone approves it.

Checked by programs

No model decides.

A verifier derives what follows and checks every rule. The verdict is pass, fail or unknown, and unknown is never counted as a pass.

How decisions are enforced

From a decision to a check on every commit.

Follow one real thread from the Masscode project building itself: where the fact graph lives, and the two second budget it promised.

Definition time

The plan is checked before any code exists.

  • MG-01Every decision produces a rule, or says why nothing is enforceable.
  • MG-02Every acceptance criterion has exactly one test task that proves it.
  • MG-08Waves respect dependencies, so nothing is built on missing ground.
  • P-02Two tasks in one wave never write the same folders.
Code time

Every commit has to keep the promises.

  • fenceThe sandbox refuses a write outside the task's folders, with the reason.
  • importsImports observed in the code must match the connections the architecture allows.
  • MG-04A criterion marked done needs a passing test execution on the commit.
  • MG-13Merged work carries an evidence bundle a named person approved.
A complete cross-cutting ontology

One vocabulary from why to proof.

Most tools keep requirements, architecture, tickets, security controls and test results in separate systems that never agree. Masscode describes all of them with one vocabulary, in twelve layers that each point back at the layers before. Concerns like personal data, security and cost are not bolted onto one layer: rules carry them across every layer they touch.

Built on open standards

A small owned core, a thin link to standards.

Masscode owns fewer than forty classes. Everything else comes from standards that other people maintain and auditors already recognise. Each Masscode class is declared a special case of a standard class, never its equivalent, so tools that only know the standard still read the graph and no other standard's mistakes are imported.

W3CRDF and RDFS

The statement, types and labels.

W3CSHACL

The checker, in a closed world: a missing fact is a violation.

W3CPROV-O

Who did what and when: agents, runs, approvals.

W3CSKOS

Word lists and the project glossary.

DCMIDublin Core terms

Identifiers, dates, versions and sources.

ISO/IEC 5962SPDX 3

Packages and licences, joined to vulnerability findings.

NISTOSCAL

Control catalogues, profiles, risks and findings.

W3C community groupDPV

Personal data categories for PIPEDA and Law 25.

Learn more

Learn the ontology, one module at a time.

The ontology course teaches the whole graph language hands on: read statements, explore every kind of element, watch derivation run, route rules to their checkers and follow a decision as it reopens. Each module ends with a short check.

  1. Facts and statements
  2. Families and status
  3. The twelve layers
  4. Links as sentences
  5. Decisions become rules
  6. Cross-cutting concerns
  7. Where facts come from
  8. The verifier
  9. Open standards
  10. When the project changes