What we are actually building, as of 2026-08-01

This document states the current, verified condition of the ShurIQ and DKR work: which systems run, which are specified but unbuilt, and which repositories and tools are real. It exists because an external agent (Manus) produced 23 video tutorials grounded in a picture of our stack that was wrong, and every downstream artifact inherited that error. Read this before writing anything that claims to describe our system.

Every claim below traces to a vault file. Where a thing is planned rather than running, it says so in those words.

The correction, stated plainly

An earlier agent read the starred and forked repositories on the jonnydubowsky GitHub account and treated them as the working system. They are not. Across 23 generated tutorials, graphify is named 97 times, knowledge-base-server-demo 78 times, obsidian-mcp 61 times, SimpleMem 46 times, mempalace 42 times, and NexAU 24 times.

None of those six repositories is part of the working stack. They are reference material and experiments. Building tutorials on top of them produced instructions that cannot be followed, because the tools they describe are not the tools we run.

The three-layer knowledge model

This is the core of the architecture and the thing most worth understanding correctly.

myKG is the producer and the typed store. It holds entities, typed edges, confidences, and attributes. Every concept space in the vault emits a myKG bundle: nodes.jsonl, edges.jsonl, schema.json, and knowledge_graph.ttl. Typed relationships live here and only here.

OKF (Open Knowledge Format) is the portable container. OKF is Google Cloud's format, version 0.1, released 2026-06-12. A bundle is a folder of Markdown files, each with YAML frontmatter whose only hard requirement is a non-empty type. OKF links carry no edge type; relationship meaning lives in prose. That poverty is deliberate on our side: it means an OKF bundle cannot carry the typed edges and second-order dynamics that myKG holds, so a bundle is a Layer 2 projection by construction.

Dotprompt supplies the verbs. A dotprompt input.schema is where an OKF record plugs in; output.schema writes records back. Dotprompt is already in production in the module gallery at projects/shur/report-grammar/module-gallery/prompts/.

The three compose. They do not compete, and OKF does not replace myKG. If OKF were abandoned tomorrow we would lose a serializer, not a system.

Why this matters for retrieval

Several videos in this corpus argue about RAG, vector databases, and graph memory. Our position is already settled in code: the vault of Markdown files is the system of record, myKG is the typed graph derived from it, and OKF is how that travels. We do not run a vector database as the primary retrieval path. Retrieval was audited across the whole system on 2026-07-24; the census of every place our agents look things up is at projects/dkr-agency/concept-space-2026-07-24-retrieval-grammar/.

The OKF toolchain, which is built and running

Located at projects/shur/okf/. Dependencies: pyyaml, plus the local claude CLI for the enrichment pass.

Tool	What it does	State
`okf_mirror.py`	Tier 1 deterministic mirror. Walks a document folder, writes one OKF concept per `.md` into a parallel `_okf/` bundle. Source documents are never touched. Idempotent via `shuriq_source_sha256`.	Built, run on many folders
`okf_extract_entities.py`	Tier 1 entity producer. Reads a myKG Obsidian vault and emits OKF concepts with REA and BMC typings from a documented 21-row class map. Preserves hand-authored concepts.	Built
`okf_enrich.py` plus `okf-concept.prompt`	Tier 2 dotprompt enrichment. Patches description and intent on weak concepts.	Built
`okf_persona_export.py`	Layer 2 persona bundle plus the deep model for the gated Worker.	Built
`okf_viz.py`	Self-contained D3 bundle visualiser, no external fetch.	Built
`shuriq-okf-profile.md`	The versioned shared standard: type vocabulary, extension keys, guards, conformance rules. Currently v0.5.1.	Built

Usage is python3 okf_mirror.py <root>, which writes to <root>/_okf/.

The profile passed the openknowledgeformat.com validator with zero blocking errors.

The export firewall, in three parts

When a bundle leaves the team, three things protect it, and none of them is encryption:

The format is too poor to carry typed edges or second-order dynamics.
A deliberate export projection chooses which types ship and which extension keys are allowed.
An authenticated rehydration endpoint sits behind the resource: URIs.

Export-safe extension keys: shuriq_source_path, shuriq_source_type, shuriq_source_sha256, shuriq_layer, shuriq_okf_generated, shuriq_rea_type, shuriq_bmc_cell, shuriq_bmc_variant, shuriq_bundle_role.

Never exported: anything matching sbpi* or dkr_*, and anything referencing typed edges or scoring internals.

A live demonstration of the gate runs at https://okf-persona-gate.jonny-a6b.workers.dev. Open routes serve Layer 2. The /rehydrate/<id> route returns 401 without a bearer token and the deep model with it.

What DKR means here

DKR is Engelbart's Dynamic Knowledge Repository: a body of knowledge continuously developed, integrated, and applied. The agent is the harness, the knowledge graph is the territory, and intent is the fuel. The canonical statement is projects/dkr-agency/DKR-SYNTHESIS-OUTLINE.md.

The governing model is Argyris and Schon: Governing Variable, then Action Strategy, then Consequences. The internet is good at single-loop correction, where you adjust the strategy, and bad at double-loop correction, where you interrogate the governing variable itself. DKR is built as a double-loop instrument. Where the large platforms build a profile about a person and never let them edit the governing variables, DKR puts those variables in the person's hands.

The DKR agent is not the personal-assistant tier that handles items and deadlines. It works on the quality and structure of what a person knows.

The operating loop, with honest status

NIGHTLY / WEEKLY PULSE
  Scout       find what is missing, by negative space      RUN TODAY
  Trailblazer map the environment and model intent         PROTOTYPE
  Social-Int  enrich the people in the picture             RUN TODAY
  SBPI        score the competitive structure              RUN TODAY
  Reports     daily, weekly, value-flow synthesis          RUN TODAY
  DKR agent   link new notes, raise legibility             PROTOTYPE

Scout uses negative-space methodology, which asks what we are not discussing rather than what we know, across absence, bridge, decay, and contradiction questions. The operations manual is projects/dkr-agency/guides/DKR-OPERATIONS-GUIDE.md.

SBPI, the scoring layer

SBPI is the Structural Brand Power Index. Two tiers, and they are never merged:

Tier 1 is universal brand health across five dimensions: Content Strength, Narrative Ownership, Distribution Power, Community Strength, Monetization Infrastructure.
Tier 2 is a per-vertical rubric.

A client is one row in a stack-ranked set of their vertical, never scored alone. The canonical dimension registry is projects/shur/value-flows/sbpi-dimension-ontology-inventory.md.

The semantic layer is a Python package, shuriq_kg, with a TripleStore abstract base class and adapters for in-memory rdflib, Oxigraph over HTTP, and GraphDB over HTTP.

Only two of those three engines work today. GraphDB's licence key expired 2026-05-22 and every query returns a licence error. It does not answer on port 7200. The running store is Oxigraph. Say two engines, not three, until the licence is renewed. Corrected 2026-08-02 after checking the port directly.

Named graphs follow https://shurai.com/graphs/{vertical}/{week}. The store held 119,054 triples as of 2026-07-30. The nightly pipeline runs at 06:13.

What actually runs today

System	Where	State
ShurIQ Report Studio	`~/Documents/projects/shuriq-report-studio/`, deployed to `shuriq-report-studio.pages.dev`	Production. Vite, React, Cloudflare Pages Functions, D1, Anthropic SDK
Report Engine Managed Agent	Anthropic managed agent `agent_01Uj1TbRtS5jAbLGNzpyKrT5`	Live since 2026-05-29
Semantic layer	`shuriq_kg` package plus Oxigraph	Live, 119,054 triples. GraphDB is licence-expired and unusable
OKF toolchain	`projects/shur/okf/`	Live
Content series	`content/build.rb` and `content/publish.rb`, deployed to `content-series-b6l.pages.dev`	Live, 13 registered series, 91 lessons
Slack agent	`projects/shur/slack-agent/`, channel `#shur-iq`	Live
Grammar gate	`projects/shur/report-grammar/grammar-gate.py`	Built, not in CI
Nightly SBPI pipeline	scheduled, 06:13	Live

The work runs out of an Obsidian vault driven by Claude Code, with skills, agent specs, and Bases dashboards. It does not run out of a conventional application repository. That is the single biggest thing an outside agent gets wrong.

The tools that are genuinely in the loop

Obsidian (the vault is the system of record), Claude Code (the harness), InfraNodus (text network analysis and knowledge graphs, reached over MCP and REST), DEVONthink, mem0 and OpenMemory (semantic recall over a REST endpoint on port 8765), Cloudflare Pages and Workers (every deploy), Oxigraph (triples), and Excalidraw.

GitHub and Jira, stated exactly

This is the part most likely to be reported wrongly, so it is written without softening.

GitHub. The organization shuriq-lab exists at https://github.com/shuriq-lab, created 2026-07-28T17:56:18Z. Team plan, five seats, three filled. jonnydubowsky is the sole owner. AsianPelican (Alex Ishida) and nac70x7 (Nicholas Crabill) have accepted and are members, so the organization has three members and zero pending invitations. Confirmed against the live API on 2026-08-02. A secret team named core exists with no members. Two-factor authentication is required, repository creation is restricted to owners, and base permission is read.

The organization contains zero repositories. No repository name has been chosen. The only candidate on record is platform. This blocks the scaffold and everything under it.

Note one constraint discovered during setup: GitHub has no private-organization setting, so the organization profile page is always publicly visible.

Jira does not exist. There is no site, no project key, no epic identifiers, and no board. The design for it is written and the instance has never been created.

The specified Jira design, for when it is created:

GitHub is the system of record for the delivery work, and Jira renders views of it. Where they disagree, GitHub wins and the sync gets fixed.
Issue types: Epic (E-01 through E-12 from the feature register, plus a registries epic), Story (S-01 through S-20), Task, and Decision (one ticket per open decision).
Workflow states: Intake, Pool, Ready, In Progress, In Review, Done.
Definition of ready is a four-field spec: outcome, reason, local exceptions, and how we will know it is right, expressed as three to six checks with at least one negative check.
On day one every transition is manual and the Jira-to-GitHub link is a URL pasted both ways by hand. No transition automation ships until the manual version has run for a full sprint.
Estimation is undecided. There are no story points anywhere.

The planned monorepo layout, which exists as a specification and as seed files, not as a repository:

<slug>/
  apps/         report-studio, command-center, atlas
  modules/      dashboard-design-studio (deferred), slack-agent, viz-studio
  engines/      kg, competitive-intel
  interfaces/   okf/
  registries/   channels.yaml, forms.yaml, readers.yaml, routes/<client>/*.yaml
  intake/       <slug>/manifest.yaml
  gates/        route-gate.py, template-gates/, grammar-gate.py
  .github/      ISSUE_TEMPLATE/, workflows/

Seed files that are written and ready to copy in on day one live at projects/shur/dev-sprint-1/monorepo-seed/. They include gates/route-gate.py, whose self-test passes 13 of 13 deterministically with no model calls, plus registries/channels.yaml (CH-01 through CH-12), forms.yaml (F-01 through F-20), and readers.yaml (R-01 only).

Decided constraints on the repository: no GitHub Projects boards, no hardcoded organization URLs, secrets tracked by name in a SECRETS.md inventory, and agent automation through a GitHub App rather than a machine user, because a bot account would consume one of five paid seats.

The delivery grammar the monorepo is organized around

Route = Channel x Form x Reader x Action, plus two gating fields, attenuates and evidence. Channel first, form last. A route declares a standing query rather than a payload. A dashboard is what a set of route declarations composes into. The claim that ties this to delivery: a route declaration and a Jira user story are the same object in two vocabularies.

Status: draft. Nothing here is signed under Schema-is-Law. Registries v0 hold 12 channels, 20 forms (11 built), and 1 reader. Zero real route declarations exist as files.

Sprint state

Sprint 1 is in specification, not execution. Preparation began 2026-07-17 and kickoff was set for 2026-07-28. The feature register holds 120 rows: 37 work today, 22 need a person, 61 are to build. Priority is empty on every row.

The order of work is: pick the repository slug, create the repository and seed the layout, land route-gate.py as the first pull request, run the kickoff session, build the sprint-1 cut, mount Jira, adjudicate registries, sign the grammar, extend style coverage, then the vertical intelligence block. Everything after step one is blocked on step one.

Roles

Person	Role
Kristine Hagedorn (KG)	Sprint lead: directives, scope, priorities, acceptance. Jira participant, not admin
Alex Ishida	Design: wireframes, design language, renderer integration
Nicholas Crabill	Front-end build and integration
Jonny Dubowsky	Architecture, backend, endpoints, pull-request review and merge
Diana Horowitz	Intake and pacing, review gates
Limore Shur	Direction and client priority calls

Jonny decides everything that moves through the system. Everyone else proposes. There is no QA function, and whether to add one is open.

Writing standards

Every document names a reader and a style guide. The mapping is projects/shur/report-grammar/STYLE-REGISTRY.md.

Technical documentation, architecture, build plans, READMEs, and specifications use Google developer documentation style.
Client reports and memos use the house voice canon at projects/trinchero/intake/deslop-voice-spec.md.
A handoff written for an agent to execute needs no style guide and should say so.

Hard rules that apply to all of it: full ISO dates, never "June 2026" or "Q2 2026". No em-dashes. No inversion rhetoric of the "not X, but Y" shape; lead affirmative. No consulting abstraction the reader cannot point to. One thought per sentence. Say each point once. A list of blocked words is enforced by the gate below; the anatomical metaphor for a central organizing thing is one of them, and the replacement is "core".

The deterministic check is python3 projects/shur/report-grammar/grammar-gate.py <file-or-dir>. It globs *.html under a directory, so Markdown files must be passed by path. The multi-agent voice check is the shuriq-megaeval skill, and it is mandatory before anything external ships.

Naming and confidentiality

ShurIQ is in stealth. Do not name the product or framework in public material. Describe it by capability. The GitHub organization slug shuriq-lab is an accepted exception, decided 2026-07-28.

Client artifacts never expose internal methodology, system vocabulary, or self-audit. Content produced for a client publishes under that client's account.

Where the concept writing lives

Published and drafted concept posts are at content/series/<slug>/pathways/<NN-pathway>/<NN-slug>.md, built by content/build.rb and deployed to https://content-series-b6l.pages.dev. There are 15 series directories, 13 of which carry a _series.yml, and 91 lesson files: 6 published, 16 ready, 69 draft. Counted directly on 2026-08-02 by matching type: content_lesson.

The densest correct explanation of the architecture is the 08-composite-intelligence pathway of the shuriq-concept-flywheel series, which runs from intake as ontology induction, through REA as a value grammar and BMC as a canvas grammar, to SBPI as the scoring pass, OKF as the shared substrate, and Totem Persona as portable identity.

Concept-space research runs live at projects/dkr-agency/concept-space-*/, each with the same shape: intake/, analysis/, mykg/, _okf/, and site/.