Programming Graphonomous with WRL

Graphonomous does not have a query language of its own and does not want one. Its program is a vocabulary — which kinds of thing exist, which relations may join which of them — and that vocabulary is a row in WallRiderLang’s profile table. The graph is submitted to WRL as a Semantic IR 2.0 artifact, WRL’s kernel mints every identity, and WRL refuses, by name, anything the row does not declare. This page shows each of those steps with the real bytes.

01The program is a profile row

WRL’s encoder holds V2_PROFILES, frozen data keyed by profile id. Graphonomous declared its vocabulary and WRL admitted it as a static row: no runtime, no film schema, no admit policy — roles, kinds and admissible (source role, target role) pairs, and nothing else. The current row, graphonomous.semantic.v2, declares 24 roles, 32 relation kinds and 103 endpoint pairs. It is v1 spread plus exactly one pair, SUPERSEDES [LAW, LAW]; v1 is v0 spread plus three roles, one kind and ten pairs. A frozen row is never edited — a wider vocabulary is a new row, and every world sealed under an earlier row keeps its id.

// WRL/relation-v2.js — the row, as data (excerpt)
roles      OBLIGATION ENFORCEMENT_PROPERTY CLAIM LAW MECHANISM DEFINITION REPRESENTATION PROFILE ASSUMPTION WITNESS FALSIFIER FINDING EXPERIMENT RECEIPT ARTIFACT ADJUDICATION EVIDENCE_STATE_TRANSITION ROUND CELL REGISTRY SOURCE_LOCATION ARGUMENT DEFEATER INSTRUMENT
domain     semantic      signature  directed · solid · arity 2 · [source, target]
rulepack   graphonomous.semantic.rules.v0
endpoints  WITNESSES   [["WITNESS","CLAIM"],["WITNESS","OBLIGATION"],["WITNESS","EVIDENCE_STATE_TRANSITION"],["RECEIPT","CLAIM"],["RECEIPT","OBLIGATION"],["RECEIPT","EVIDENCE_STATE_TRANSITION"],["WITNESS","ARGUMENT"]]
           SUPERSEDES  [["CLAIM","CLAIM"],["ROUND","ROUND"],["EVIDENCE_STATE_TRANSITION","EVIDENCE_STATE_TRANSITION"],["LAW","LAW"]]
           ATTACKS     [["FALSIFIER","CLAIM"],["FALSIFIER","MECHANISM"],["DEFEATER","CLAIM"],["DEFEATER","ARGUMENT"],["DEFEATER","ASSUMPTION"],["DEFEATER","INSTRUMENT"],["DEFEATER","RECEIPT"]]
           LOCATED_IN  [["*","SOURCE_LOCATION"]]   // * = any role

The full table, with every count read out of the module by WRL’s own conformance suite: wrl.traaviis.com/reference#profiles. The rule is Core Part II §D8.20.

02The submission is an artifact, not a query

lib/wrl_world.mjs builds the world from a projection: every node and every source location becomes an object with the profile’s one port, every statement becomes a named relation whose name is the statement’s logical id. Nothing in that module sorts, de-duplicates or hashes — WRL decides object order, seed order, duplicate seeds, endpoint pairs, the policy vocabulary and the bytes. This is the baseline projection’s world, first two objects and first relation, exactly as submitted (1080 objects and 588 relations in full):

{
 "ir_version": "2.0",
 "profile_id": "graphonomous.semantic.v0",
 "semantic_policies": {
  "rulepack_id": "graphonomous.semantic.rules.v0"
 },
 "objects": [
  {
   "object_id": "adjudication_3Agpt_3Aexec_2Dv2_3As4",
   "ports": [
    "node"
   ],
   "role": "ADJUDICATION",
   "static_config": {
    "attrs": {
     "adjudicator": "GPT-5.6",
     "authority": "advisory",
     "document": "package-v2.7/inputs/R10PRE_EXECUTION_V2_GPT56_ADJUDICATION.md",
     "line": 277,
     "section": "4"
    },
    "lid": "adjudication:gpt:exec-v2:s4"
   }
  },
  {
   "object_id": "adjudication_3Agpt_3Aexec_2Dv3_3Aclosures",
   "ports": [
    "node"
   ],
   "role": "ADJUDICATION",
   "static_config": {
    "attrs": {
     "adjudicator": "GPT-5.6",
     "authority": "advisory",
     "document": "package-v2.7/inputs/R10PRE_EXECUTION_V3_GPT56_ADJUDICATION.md",
     "section": "1-8"
    },
    "lid": "adjudication:gpt:exec-v3:closures"
   }
  }
 ],
 "relations": [
  {
   "identity_seed": {
    "relation_name": "rel:g0:ADJUDICATED_BY:claim:crosswalk:E-13b:adjudication:gpt:exec-v4:s1",
    "variant": "named-initial"
   },
   "revision": {
    "attributes": {},
    "domain": "semantic",
    "endpoints": [
     {
      "role": "source",
      "terminal": {
       "object_id": "claim_3Acrosswalk_3AE_2D13b",
       "port": "node"
      }
     },
     {
      "role": "target",
      "terminal": {
       "object_id": "adjudication_3Agpt_3Aexec_2Dv4_3As1",
       "port": "node"
      }
     }
    ],
    "kind": "ADJUDICATED_BY",
    "orientation": "directed",
    "policy": "graphonomous.semantic.rules.v0",
    "texture": "solid"
   }
  }
 ]
}

03The seal, and who minted what

WRL canonicalises, serialises and hashes; the world id is a real sem- and every relation gets the kernel’s rel- (allocation, world-scoped) and rev- (revision, world-independent). Graphonomous records them and records who minted them. Across worlds that share statements, the rev- of a statement is the same and its rel- is not — what a statement is does not depend on the world; where it is allocated does.

04What WRL refuses, by name

A two-object world in the same shape — a RECEIPT that WITNESSES a CLAIM — seals under the row to sem-e717109f49233a79fd29b34d8521096a66dc05cd2bdcbca22a91b285649c8ee3 (re-sealed twice while this page was generated: same id both times; its one relation is rel-6854a7e61b938004744c…). Each of the six edits below was then made to a fresh copy and offered to the same seal. None of them minted an id. The code is the refusal’s name; the message is WRL’s own.

The Graphonomous side runs a courtesy pre-check that names the WRL code the same input would draw, with the offending logical id in the message — and then submits anyway. WRL is the authority once an artifact exists; a test in the lane exists precisely to catch Graphonomous shadowing a WRL code with one of its own.

05Where Super (CD) comes in

The three-family snapshot pins 7 repositories by commit, tree and blob, and the adapters read those bytes and nothing else. Super is one of them: its README and the ampd runtime’s README are authoritative sources, and the crosswalk’s evidence records cite Super’s release receipts. That is the integration as it stands — Graphonomous reads Super’s evidence at a pinned commit and can be held to it. Graphonomous does not run inside Super, and Super does not call Graphonomous. A moved blob is refused (SOURCE_MOVED), not silently re-read.

06Run it yourself

# in a ProjectAmp2 checkout with WRL/ and TRVM/ beside graphonomous/
cd graphonomous/v2
node bin/g0.mjs verify     --dir projections/baseline    # the projection root re-derives
node bin/g0.mjs world      --dir projections/baseline    # seals through WRL; prints the sem-
node bin/g0.mjs check-cert --dir projections/baseline    # TRVM certificate; exit 1 on REFUSED
G0_TEST_CONCURRENCY=1 npm run test:full-tree             # 183 tests · 182 pass · 1 skipped by design

What this page does not claim: that anyone outside this machine has reproduced these numbers, that the graph is useful rather than merely sound, or that Super and Graphonomous are coupled at runtime. The ids above are real and will move the day a projection is re-minted; the page says which commit they were read at and a reader can re-read them there.

All demos · graphonomous.com · WallRiderLang · Super (CD)