Skip to content
🚧 Early alpha — building the foundation. See the roadmap →

Research challenges

Updated

These are adversarial/exploratory research briefs — focused assignments that can be handed to a fresh agent with no prior context bias. Each challenge:

  • Targets a specific architectural assumption, decision, or design
  • Asks the agent to critically assess, stress-test, or find alternatives
  • Is grounded in first principles and the project’s philosophical pillars
  • Thinks long-term and large-scale — not just “does this work today” but “does this hold at 100K notes, 50 frameworks, 10 years from now”
  1. Pick a challenge from the list below
  2. Hand it to a fresh agent (one with no prior conversation context about this project)
  3. Point the agent at the KB (docs/src/content/docs/) for context
  4. Let it research, critique, and report
  5. Log findings in zz-log/ if they surface decisions or insights worth preserving

Every agent that works on a project accumulates context bias — it starts agreeing with past decisions because it helped make them. A fresh agent given only the KB and a challenge brief can find blind spots that embedded agents can’t see.

Filed 2026-05-08 — ontology-web alignment + landscape audit (synthesis-log finalization blockers)

Section titled “Filed 2026-05-08 — ontology-web alignment + landscape audit (synthesis-log finalization blockers)”

The 2026-05-08 alignment review surfaced that the synthesis log had drifted GRC-coded and that several v0.1.7+ commitments rest on assumptions never validated under the ontology-web framing. Nine challenges were filed to close the gap. Briefs are filed; fresh-agent runs are deferred to user’s schedule.

NEW challenges (questions never asked before):

  • Challenge 29: Ontology-web query verbs — adversarial validation — “Are these the right LEGO bricks for asking questions about ontology webs?” Stress-tests the 7-primitive set (filter / project / traversal / closure / anti-join / pivot / aggregate) against SPARQL/Datalog/OLAP/SKOS/SSSOM/OLIR prior art. Direct input to settled-item #14 in synthesis log + concepts/query-primitives.mdx lock.
  • Challenge 30: View shape taxonomy — “Beyond pivot, what shapes does the engine need? (graph, hierarchy, timeline, sankey, treemap…)” Direct input to concepts/view-shapes.mdx lock + v0.2+ roadmap.
  • Challenge 31: Recipe query: block schema design — “How does a recipe declare its query in YAML?” Compares to SPARQL CONSTRUCT / GraphQL / dbt / LookML / Cube.dev. Deliverable: working JSON Schema + 3-5 reference recipes. Direct input to D8.
  • Challenge 32: Intuitive query UX — “How does a user go from intent to a working .base file?” Wizard / recipe-picker / inline-editor analysis. v0.2+ UX work.
  • Challenge 33: Multi-modal query engine landscape audit — Survey DuckDB+DuckPGQ, Polars, Cozo, Oxigraph-WASM, Stardog, RDF4j, Materialize, Datomic, ClickHouse, LanceDB. Re-audit prior engine commitments under ontology-web framing. v0.1.7+ substrate decisions; updates Ch 24 migration triggers.
  • Challenge 34: Streaming / chunked query execution — “How does merging scale chunk-by-chunk to not blow memory?” Genuine gap — prior streaming refactor (v0.1.4.5) handled IMPORT only; query side is not designed.

RERUN challenges (revisit prior commitments under ontology-web framing — original briefs preserved):

  • Challenge 35: Graph→tabular bridging (RERUN of Ch 10) — Original answered for SSSOM/GRC at small-medium scale; rerun asks for arbitrary ontology webs (BioPortal, OBO Foundry, OLS, UMLS scale). The user’s framing “we’re pulling tabular views from graph/web-connected networks” was the central question; original only nipped at it.
  • Challenge 36: Query language under ontology-web framing (RERUN of Ch 12) — Original asked Datalog vs SQL narrowly for SSSOM chain-rules; rerun asks the broader question — what language does the recipe author / user actually write? Bases DSL / SQL / SPARQL / Datalog / Cypher / GraphQL.
  • Challenge 37: Tier 2-Lite scale model (RERUN of Ch 18) — Original ceiling was ~100K mappings sized for GRC vault; rerun asks the same scale question for ontology-web vaults (BioPortal: 700+ ontologies; UMLS: 3.5M concepts; OBO Foundry: hundreds × thousands). Substrate may not survive.

Rerun convention: original briefs (Ch 10/12/18) stay archived as historical record. Each rerun is a NEW brief with a fresh Ch number that explicitly anchors to the original as predecessor and frames “what’s different now”. Original deliverables preserved verbatim; reruns produce NEW deliverables that may revise prior verdicts.

Filed 2026-06-01 — unified model: spine, backbone, audit role (pre-ingestion gate)

Section titled “Filed 2026-06-01 — unified model: spine, backbone, audit role (pre-ingestion gate)”

The full security & GRC framework corpus is assembled; the next phase is ingesting it into Crosswalker. Before that, the unified-model assumptions (inherited, not tested) get stress-tested — most pointedly “is CRI the spine?”. These three run roughly in order (39 → 40 → 41); 40 and 41 partly depend on 39’s outcome.

Challenges that have been resolved by a research deliverable and a corresponding log entry. The brief itself is preserved (re-runnable) — see each archived file for the resolution callout pointing to the resolving log.