feat(knowledge-tree): canon layer — laws, ontology, research corps, foundation graph#44
feat(knowledge-tree): canon layer — laws, ontology, research corps, foundation graph#44frankxai wants to merge 3 commits into
Conversation
…oundation graph Establish the Starlight Knowledge Tree as a full sovereign vertical with the substrate file contract, turning the shipped explorer into a governed, civilizational-scope research program. Canon layer (verticals/knowledge-tree/): - README / SOUL / SYSTEM — vision, essence, five-layer architecture + data flow - LAWS.md — 13 epistemic + operational invariants (provenance, adversarial verification, human merge gate, privacy boundary, open licensing) - ONTOLOGY.md — closed 7-kind / 4-relation graph vocabulary + open-standard mappings (schema.org / SKOS / W3C PROV / JSON-LD) - RESEARCH_PROTOCOL.md — the verifiable harvest → synthesize → verify → curate loop, designed on the assumption that hallucination is the default - AGENTS.md — 7-role research corps runnable on any SKILL.md-compatible harness - SKILL.md — auto-loading vertical skill (open SKILL.md standard) - INTEGRATIONS.md — open-first API + standards registry (OpenAlex, Wikidata, arXiv, Crossref, MCP, A2A, C2PA, persistent identifiers) - ROADMAP.md / MEMORY.md — phased build-out + instance state Canonical data: - data/graph.json — 9 domains (5 foundation + 4 path), 95 nodes, 101 edges, 14 quests, 7 provenance-anchored evidence nodes. Foundation trunk covers mathematics, physics-cosmos, life-mind, computation-intelligence, energy-matter with laws-as-concepts, landmark evidence (DOI-anchored), and well-posed open-problem quests (Riemann, P vs NP, quantum gravity, dark sector, origin of life, consciousness, AGI/alignment, room-temp superconductivity, ...). Path domains ported from the site seed as a superset. - data/graph.schema.json — JSON Schema for canon + proposals - data/validate.mjs — zero-dep validator enforcing schema + Laws (provenance, ontology closure, ID grammar, no dangling edges, quest lattices). PASSES. Registry + surface: - VERTICALS.md — register Knowledge Tree as substrate-tier sovereign vertical - site: point ONTOLOGY_URL at the now-real ONTOLOGY.md (was repo root → 404 risk) Substrate-tier: creation + ontology are /starlight-board + Frank-ack gated. This branch/draft-PR is the proposal, not a merged decision. Built on SIP — Starlight Intelligence Protocol. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01A6T9tAz1hMC2c8EWnPGEKT
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request establishes the 'Knowledge Tree' sovereign vertical by introducing a comprehensive set of architectural, ontological, and procedural documents, alongside a canonical graph dataset (graph.json), a validation schema, and a validator script (validate.mjs). Feedback focuses on correcting data inconsistencies in graph.json—specifically addressing mismatched domain prefixes and reversed part-of edge directions. Additionally, improvements are suggested for validate.mjs to prevent potential crashes on malformed input and to enforce prefix-to-domain mapping integrity, alongside a request to clarify verification voting requirements in RESEARCH_PROTOCOL.md.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| "domainPrefixes": { | ||
| "math": "mathematics", | ||
| "phys": "physics-cosmos", | ||
| "bio": "life-mind", | ||
| "comp": "computation-intelligence", | ||
| "energy": "energy-matter", | ||
| "ai": "ai-architect", | ||
| "space": "space-builder", | ||
| "creator": "creator-founder" | ||
| }, |
There was a problem hiding this comment.
There is an inconsistency in domainPrefixes: bio is mapped to life-mind, but the nodes in the life-mind domain actually use the life prefix (e.g., life/concept/evolution). Meanwhile, the bio-intelligence domain nodes use the bio prefix, but bio-intelligence is not mapped in domainPrefixes. Updating the mappings resolves this discrepancy.
"domainPrefixes": {
"math": "mathematics",
"phys": "physics-cosmos",
"life": "life-mind",
"comp": "computation-intelligence",
"energy": "energy-matter",
"ai": "ai-architect",
"space": "space-builder",
"bio": "bio-intelligence",
"creator": "creator-founder"
},| if (nodeIds.has(n.id)) err(`duplicate node id: ${n.id}`); | ||
| nodeIds.add(n.id); |
There was a problem hiding this comment.
If a node in graph.json is missing the id field, the validator will crash with a TypeError when attempting to call split on n.id at line 48. Adding a type check and guard at the beginning of the loop prevents this crash and allows the validator to report a clean validation error.
| if (nodeIds.has(n.id)) err(`duplicate node id: ${n.id}`); | |
| nodeIds.add(n.id); | |
| if (!n.id || typeof n.id !== "string") { | |
| err("node missing or invalid id: " + JSON.stringify(n)); | |
| continue; | |
| } | |
| if (nodeIds.has(n.id)) err("duplicate node id: " + n.id); | |
| nodeIds.add(n.id); |
| if (!ID_RE.test(n.id)) err(`node id violates grammar <prefix>/<kind>/<slug>: ${n.id}`); | ||
| if (!KINDS.includes(n.kind)) err(`node ${n.id}: bad kind "${n.kind}"`); // ontology closure | ||
| if (!n.label || !n.summary) err(`node ${n.id}: missing label/summary`); | ||
| if (n.domainId && !domainIds.has(n.domainId)) err(`node ${n.id}: unknown domainId "${n.domainId}"`); |
There was a problem hiding this comment.
The validator currently checks that n.domainId is valid, but it does not verify that the prefix used in n.id actually matches the registered prefix for that domain in meta.domainPrefixes. Adding this check ensures prefix-to-domain mapping integrity.
| if (n.domainId && !domainIds.has(n.domainId)) err(`node ${n.id}: unknown domainId "${n.domainId}"`); | |
| if (n.domainId && !domainIds.has(n.domainId)) err("node " + n.id + ": unknown domainId \"" + n.domainId + "\""); | |
| const prefix = n.id.split("/")[0]; | |
| const expectedDomainId = graph.meta?.domainPrefixes?.[prefix]; | |
| if (expectedDomainId !== n.domainId) { | |
| err("node " + n.id + ": prefix \"" + prefix + "\" maps to \"" + expectedDomainId + "\" in domainPrefixes, but node has domainId \"" + n.domainId + "\""); | |
| } |
| const requiresBySource = new Set(graph.edges.filter((e) => e.relation === "requires").map((e) => e.source)); | ||
| for (const n of graph.nodes.filter((n) => n.kind === "quest")) { | ||
| if (!requiresBySource.has(n.id)) warn(`LAW-5: quest ${n.id} has no 'requires' edges (prerequisite lattice missing)`); | ||
| } |
There was a problem hiding this comment.
If graph.edges or graph.nodes is missing or null, calling .filter directly on them will throw a TypeError. Using nullish coalescing operators (?? []) makes the validator more robust against malformed or partial graph files.
| const requiresBySource = new Set(graph.edges.filter((e) => e.relation === "requires").map((e) => e.source)); | |
| for (const n of graph.nodes.filter((n) => n.kind === "quest")) { | |
| if (!requiresBySource.has(n.id)) warn(`LAW-5: quest ${n.id} has no 'requires' edges (prerequisite lattice missing)`); | |
| } | |
| const requiresBySource = new Set((graph.edges ?? []).filter((e) => e.relation === "requires").map((e) => e.source)); | |
| for (const n of (graph.nodes ?? []).filter((n) => n.kind === "quest")) { | |
| if (!requiresBySource.has(n.id)) warn("LAW-5: quest " + n.id + " has no 'requires' edges (prerequisite lattice missing)"); | |
| } |
| "source": "comp/concept/information-theory", | ||
| "target": "ai/concept/information-theory", | ||
| "relation": "part-of", | ||
| "note": "path node specializes the foundation" | ||
| }, | ||
| { |
There was a problem hiding this comment.
The direction of this part-of relation is reversed. According to ONTOLOGY.md, part-of means 'Source is a component of target'. Since the path node ai/concept/information-theory specializes/is a component of the broader foundation node comp/concept/information-theory, the path node should be the source and the foundation node should be the target.
{
"source": "ai/concept/information-theory",
"target": "comp/concept/information-theory",
"relation": "part-of",
"note": "path node specializes the foundation"
},| { | ||
| "source": "life/concept/cell-biology", | ||
| "target": "life/concept/molecular-biology", | ||
| "relation": "part-of" | ||
| }, |
There was a problem hiding this comment.
The direction of this part-of relation is reversed. According to ONTOLOGY.md, part-of means 'Source is a component of target'. Since molecular biology is a component of cell biology (molecules make up cells), life/concept/molecular-biology should be the source and life/concept/cell-biology should be the target.
| { | |
| "source": "life/concept/cell-biology", | |
| "target": "life/concept/molecular-biology", | |
| "relation": "part-of" | |
| }, | |
| { | |
| "source": "life/concept/molecular-biology", | |
| "target": "life/concept/cell-biology", | |
| "relation": "part-of" | |
| }, |
| - Are the edges real? (A plausible-sounding `requires` that experts would reject is worse than a missing edge.) | ||
| - Default to *refuted* when uncertain. | ||
|
|
||
| For `established`-confidence claims and all quest framings, use three verifier votes with distinct lenses (source-fidelity, confidence-honesty, edge-validity); majority refute kills or downgrades the claim. Single-vote verification is acceptable for `speculative`/`contested` labels and copy-level edits. |
There was a problem hiding this comment.
The protocol does not explicitly state whether supported confidence claims require single-vote or three-vote verification. Clarifying this removes ambiguity for agents and contributors executing the protocol.
| For `established`-confidence claims and all quest framings, use three verifier votes with distinct lenses (source-fidelity, confidence-honesty, edge-validity); majority refute kills or downgrades the claim. Single-vote verification is acceptable for `speculative`/`contested` labels and copy-level edits. | |
| For `established`-confidence claims and all quest framings, use three verifier votes with distinct lenses (source-fidelity, confidence-honesty, edge-validity); majority refute kills or downgrades the claim. Single-vote verification is acceptable for `supported`/`speculative`/`contested` labels and copy-level edits. |
…ons, validator hardening Resolves gemini-code-assist review on PR #44: - graph.json meta.domainPrefixes (HIGH): add life→life-mind and correct bio→bio-intelligence. When foundation life nodes were re-prefixed bio/→life/ to avoid colliding with the bio-intelligence path domain, the prefix map was left stale (life unmapped, bio pointing at the wrong domain). - graph.json: reverse two backwards part-of edges (part-of = source is a component of target, per ONTOLOGY.md): molecular-biology part-of cell-biology (molecules compose cells) ai/information-theory part-of comp/information-theory (path specializes foundation) - validate.mjs: guard against missing/invalid node id (no crash on split); enforce id-prefix → domainId integrity via meta.domainPrefixes (this check would have caught the bug above); null-safe (?? []) on nodes/edges in the LAW-5 quest pass. - RESEARCH_PROTOCOL.md: clarify `supported` confidence uses single-vote verification (was ambiguous between the single- and three-vote tiers). Validator PASSES with the stricter prefix→domain check (95 nodes / 101 edges; 28 draft-grade warnings on un-sourced seed path nodes, as expected). Built on SIP — Starlight Intelligence Protocol. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01A6T9tAz1hMC2c8EWnPGEKT
|
Thanks for the review — all seven points were valid and are fixed in
Validator passes with the stricter check (95 nodes / 101 edges; the 28 remaining warnings are the un-sourced seed path nodes, intentionally flagged as draft-grade Phase 3 harvest targets). Note this PR stays in draft by design — it's substrate-tier (new vertical + ontology) and awaits Generated by Claude Code |
…TING, CI canon gate Make the research loop runnable by anyone (human or agent) and make the Laws CI-enforced rather than advisory. - .github/workflows/knowledge-tree-canon.yml: runs the zero-dependency validator on every PR/push touching verticals/knowledge-tree/data/**. Enforces schema + Laws (provenance, ontology closure, ID grammar, prefix→domain integrity, no dangling edges, quest lattices). Independent of the heavier harness-check job (no npm install needed). - .github/ISSUE_TEMPLATE/kt-node-proposal.yml + kt-quest-proposal.yml: provenance-enforcing proposal forms. Node form requires kind (closed set), ID grammar, summary, confidence (LAW-4), refs (LAW-1), and a Laws checklist; quest form requires statable success criteria + a `requires` prerequisite lattice (LAW-5). - .github/ISSUE_TEMPLATE/config.yml: keeps blank issues enabled; links the ontology + contributing guide. - verticals/knowledge-tree/CONTRIBUTING.md: the operational how-to for humans and agents — the seven-role loop, what gets rejected, licensing. - MEMORY.md: T-003 closed; decision logged. Validator PASSES; all issue-form + workflow YAML parses clean. Operational-tier (tooling around the already-proposed canon) — no new ontology/law surface. Built on SIP — Starlight Intelligence Protocol. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01A6T9tAz1hMC2c8EWnPGEKT
2 participants
Summary
Turns the shipped Knowledge Tree explorer into a full sovereign vertical — a governed, civilizational-scope research program for mapping all verifiable knowledge, for humans and agents. Adds the substrate file contract, the foundational laws, a formal ontology, a verifiable research loop, a cross-harness agent corps, and a schema-validated canonical graph anchored in the foundations of mathematics, physics, life, computation, and energy.
This is the "massive civilizational project" layer: not a prettier graph, but the canon and governance that let any capable agent (Claude, Codex, Gemini, Grok, Nous Hermes-class) conduct research against a provenance-carrying map and help extend the frontier.
What's in this PR
Canon layer —
verticals/knowledge-tree/(symmetric withpeople-intelligence/):README/SOUL/SYSTEM— vision, non-negotiable essence, five-layer architecture (substrate → research → verification → canon → surface) with one-way data flowLAWS.md— 13 invariants: provenance-or-it-doesn't-exist, adversarial verification, human merge gate, honest confidence, falsifiable quests, no deletion of history, the privacy boundary, open licensing, cross-vendor by constructionONTOLOGY.md— closed 7-kind / 4-relation vocabulary + mappings to schema.org / SKOS / W3C PROV / JSON-LD so the graph is linked-data addressableRESEARCH_PROTOCOL.md— the harvest → synthesize → verify → curate → record loop, designed on the assumption that hallucination is the substrate's defaultAGENTS.md— 7-role research corps (Cartographer · Harvester · Synthesizer · Verifier · Questwright · Curator · Sentinel), each defined by inputs/outputs/refusals, runnable on any SKILL.md-compatible harnessSKILL.md— auto-loading vertical skill in the open SKILL.md standardINTEGRATIONS.md— open-first API + standards registry (OpenAlex, Wikidata, arXiv, Crossref, Semantic Scholar, PubMed, NASA ADS; MCP, A2A, C2PA, persistent identifiers)ROADMAP.md/MEMORY.md— phased build-out (Phase 0–5) + live instance/tasking stateCanonical data —
verticals/knowledge-tree/data/:graph.json— 9 domains (5 foundation + 4 path), 95 nodes, 101 edges, 14 quests, 7 DOI-anchored evidence nodes. Foundation trunk: mathematics · physics-cosmos · life-mind · computation-intelligence · energy-matter — with laws-as-concepts, landmark evidence (Gödel, Higgs, GW150914, DNA structure, Human Genome, AlphaFold, NIF ignition), and well-posed open-problem quests (Riemann, P vs NP, quantum gravity, dark sector, origin of life, consciousness, AGI/alignment, room-temp superconductivity, grid storage). Cross-domain bridges (physics→calculus, QM→linear algebra, chemistry→biology) are first-class. Path domains ported from the site seed as a superset.graph.schema.json— JSON Schema validating canon + proposalsvalidate.mjs— zero-dependency validator enforcing schema + Laws (provenance, ontology closure, ID grammar, no dangling edges, quest prerequisite lattices). PASSES — warnings correctly flag the un-sourced seed path nodes as draft-grade (Phase 3 harvest targets).Registry + surface:
VERTICALS.md— register Knowledge Tree as a substrate-tier sovereign verticalsite/src/app/knowledge-tree/page.tsx— pointONTOLOGY_URLat the now-realONTOLOGY.md(previously the repo root, a latent 404)The repo constellation (SYSTEM.md / README.md)
Sharp boundaries, canon → surface one-way:
/starlight-board, attestation, agent corps)starlight-knowledge-tree(public) — mirror target for the forkable canon (Phase 2)site— starlightintelligence.org surfaces; hydrate from canon, never authorVerification
node verticals/knowledge-tree/data/validate.mjs→ PASS (schema + laws clean; 9 domains / 95 nodes / 101 edges)graph.json+graph.schema.jsonparse as valid JSON<prefix>/<kind>/<slug>; no dangling edges; foundation quests carryrequireslatticestsc; change is type-trivial)Governance
Substrate-tier. Creating a vertical and defining an ontology touches canon — this is
/starlight-board+ explicit Frank-ack gated per the SIS governance rules. This draft PR is the proposal, not a merged decision. Requesting Board review before merge; the ontology's closed kind/relation sets and the Laws are the load-bearing parts to pressure-test.Follow-ups (tracked in MEMORY.md)
graph.json; mirror canon to the public repoSKILL.md+AGENTS.mdto claude-skills-library🤖 Generated with Claude Code
https://claude.ai/code/session_01A6T9tAz1hMC2c8EWnPGEKT
Generated by Claude Code