A guide to the DreamLab estate: what each system owns, how they connect, and what is ready to use.
Website · Start here · Architecture · Status · Documentation
VisionFlow connects knowledge authoring, formal reasoning, agent execution, human review and self-owned data. The aim is practical: let agents work on shared knowledge while people retain authority over what becomes accepted knowledge, with an inspectable record of the decision.
This repository maintains the ecosystem architecture, compatibility records, diagrams and public website. Install the individual products from their own repositories; build this checkout to preview or improve the website.
The vision report and ecosystem pitch explain the strategic argument. The repository map and compatibility matrix describe the implementation boundaries.
| You want to… | Start with | What it owns |
|---|---|---|
| Write an ontology as Markdown | Ontomark and its Obsidian plugin | Parsing, typed models, reasoning, compilation and reviewed note edits |
| Explore knowledge spatially | VisionClaw | Knowledge graph, GPU layout, desktop/XR clients and governed knowledge workflows |
| Give agents a controlled working environment | Agentbox | Nix-composed runtime, tools, memory adapters, identity and capability policy |
| Ground model answers in your corpus | Loom | Retrieval and context assembly behind a model-swappable serving interface |
| Own and serve personal or agent data | solid-pod-rs | Solid storage, access control, identity and tier-specific server features |
| Host a Nostr community and governance surface | nostr-rust-forum | Forum kit, relay and human/agent communication |
| Deploy DreamLab's branded site | dreamlab-ai-website | Marketing content and operator configuration consuming the forum kit |
| Inspect the published corpus | knowledgeGraph | Public corpus distribution at narrativegoldmine.com |
| Build agent payment or sidechain applications | sidestr-rs | Rust protocol, wallet, settlement and channel libraries; deployment is separate |
| Propose measured repository improvements | dream-engine | Evidence-gated experiment and judgement crates; a host supplies the nightly driver |
| Collaborate around a codebase in 3D | Codescape | Code graph, layout, agent activity and voice collaboration, isolated from knowledge work |
| Study haptic graph interaction | visiontouch-rs | Private supporting device study; proof of principle, with hardware acceptance separate |
The site's six substrates are a conceptual grouping, not the total repository count. Libraries, authoring tools, published data and supporting studies have their own release and acceptance boundaries. The nightly health roster also includes supporting repositories beyond this table.
flowchart TB
AUTHOR["Author: Markdown notes"] --> OM["Ontomark: parse, validate, reason, compile"]
PLUGIN["Obsidian plugin: local authoring and reviewed edits"] --> AUTHOR
OM --> BUNDLE["Versioned ontology artefacts"]
BUNDLE --> KG["knowledgeGraph: public distribution"]
BUNDLE --> VC["VisionClaw: knowledge graph and spatial observation"]
BUNDLE --> LOOM["Loom: retrieval and model grounding"]
LOOM --> AB["Agentbox: controlled agent execution"]
AB -->|"proposals and activity"| VC
AB -->|"scoped data access"| POD["solid-pod-rs: personal data"]
FORUM["nostr-rust-forum: communication and review"] -.->|"governance event contract"| VC
FORUM --> EDGE["dreamlab-ai-website: branded consumer"]
CS["Codescape: separate code graph"] -.->|"shared wire and host deployment"| VC
DE["dream-engine: measured improvement proposals"] --> HOST["Repository-specific nightly hosts"]
SR["sidestr-rs: economic protocol libraries"] -.->|"consumer-specific integration"| AB
Arrows describe ownership and intended data flow; they do not certify that every edge is active in one deployment. Solid pods, governance events, grounding requests and graph-position frames have different contracts. The cross-estate diagrams and compatibility matrix track those seams explicitly.
- An author writes Markdown with ontology frontmatter. Ontomark builds a typed model, reports unsupported constructs and produces machine-readable artefacts.
- Consumers use an identified corpus generation. VisionClaw makes knowledge visible; Loom selects context for model requests. Private working knowledge and public releases remain distinct projections.
- An agent proposes a change. The human review path and consistency checks decide whether it may proceed; a proposal is not an accepted fact.
- A pull request or reviewed edit carries the change through the owning repository's workflow. Merge observation and downstream refresh depend on the configured adapters and credentials.
Read the sovereign corpus contracts, identity spine and mesh smoke-test procedure for the integration requirements. These boundaries matter for research corpora, engineering handover, organisational knowledge and immersive teaching alike.
Identity, reasoning and grounding: the terms used across the estate
The identity spine uses did:nostr identifiers derived from secp256k1 public keys. Each service still needs its own verification, authorisation, replay and key-custody policy. Sharing an identifier does not grant a capability or establish that every consumer implements the same policy.
An ontology defines vocabulary and axioms. A knowledge graph holds represented knowledge using those terms. Reasoning derives consequences under the engine's supported formal profile. Grounding selects corpus material for a model's context. None of these alone proves that a claim in the corpus is true or that a generated answer is correct.
The published corpus is a testbed that includes synthetic material, rather than an authoritative encyclopaedia. Research results must retain their dataset, model and evaluation scope. See the terminology guide, Loom research and published corpus repository.
The website is static HTML, CSS and JavaScript with a WebGL2 mesh experience. Its build copies the static tree, stages declared assets and writes an asset receipt. Node is required for the build scripts; there is no Rust or WASM compilation step.
npm ci
npm run build
# Output: website/dist/
# Serve it locally with any static HTTP server, for example:
python3 -m http.server 8000 --directory website/distOpen http://localhost:8000. Python is only one option for serving the built files.
npm run check:assets
npm run test:gates
# Full verification also needs the external Chrome/CDP sidecar:
npm run verifyThe sidecar prerequisites and browser checks are documented in site verification. A successful static build establishes that the declared assets can be staged; it does not establish that a browser journey or a sibling service works.
What CI publishes and checks
deploy.yml builds website/static/ through website/build.sh, checks the candidate and uploads website/dist/ as a GitHub Pages artefact. The build writes www.visionflow.info into its CNAME.
Blocking publication checks cover the declared asset inventory, build output, internal links, metadata, structured data and diagram baseline. The drift counter's enforcement depends on whether the pinned sibling source is available. The build receipt tooling records the artefact revision, asset hashes and inventory results.
The estate-health workflow collects repository and public-surface information into estate-health.json. The website displays that committed snapshot. It is dated evidence, not a query made when a visitor opens the page.
The dream configuration supplies this repository's improvement evaluators. An accepted experiment is not a deployment or proof of cross-estate acceptance.
Reviewed 21 October 2026. This repository ships documentation, site assets and verification tooling. Runtime claims belong to their implementation repositories. Read a status word together with its revision, feature flags, deployment configuration and acceptance evidence.
| Surface | What this checkout establishes | What needs separate evidence |
|---|---|---|
| Public website | Static source, build, asset inventory and publication workflow | Current deployed revision and browser behaviour |
| Architecture and diagrams | A traceable source map with declared revision stamps | Semantic review after source changes; live integration |
| Estate health | A CI-collected, committed snapshot | Anything that changed after collection |
| Shared ontology | Ontomark ownership and explicit consumer projections are documented | Consumer upgrades, generation alignment and deployment |
| Governance | Proposal, review and identity contracts are documented | A complete configured live session across the participating services |
| Dreaming | Repository-specific experiment configuration and records | Host activation and any estate-wide orchestration claim |
| GPU, XR and haptics | Product-specific source and evidence links | Hardware acceptance on the intended device |
The canonical maturity vocabulary is explained in the status reconciliation. Do not raise the maturity of a whole mesh from a passing unit test, a package release or a single working consumer.
Recent changes to follow in the implementation repositories
- Shared authoring and certificates: Ontomark's compiler is the shared producer. The recent derivation-certificate work and VisionClaw's
vault certify/ consequence-delta tooling extend the explanation of inferred consequences. Follow Ontomark's decisions and the VisionClaw ontology diagram at their declared revisions. - Codescape extraction: the code-graph product has its own repository and workspace. It shares wire/deployment contracts with VisionClaw while excluding the knowledge-work stores. See the Codescape diagram and its governing baseline.
- Dream Engine extraction: the current Rust crates are distinct from the historical TypeScript fork. The estate diagram separates library publication from Agentbox adapter activation.
- Pod forge and mirror: ADR-2019 records the consumer-specific policy. The decision, compiled features, running service and configured follow list are separate facts; the forum's Worker tier cannot run a native git forge.
To improve the canon, change the relevant source document, follow its implementation links and update assertions that the current code no longer supports. Keep historical evidence dated. For website changes, run the build and appropriate publication checks before proposing the change.
Maintained by DreamLab AI and John O'Hare; see MAINTAINERS.md. The Solid and identity lineage includes Melvin Carvalho's JavaScriptSolidServer, DID:Nostr and Web Ledgers.
Licences vary across the estate: server/application code, permissive libraries, published data and third-party assets have distinct terms. Use each repository's licence and notices. This checkout has no root licence grant; its licence notes require maintainer confirmation for reuse of local documentation and website assets outside the ecosystem. The licensing map is a navigation aid, not a substitute for those terms.