Mystery School Sense-Making Architecture

The invitation

Open Source Mystery School is envisioned as a luminous tome, constellation, and accessible linear projection over canonical Dragon teachings. This proposal defines the sense-making field beneath those surfaces: a fast, inexpensive, inspectable way to find obvious relationships, hidden correspondences, semantic spines, and cross-tradition echoes across the complete public Dragon corpus.

The experiment begins with one deliberate refusal: the model does not define an opaque embedding space and it does not become an authority. We define the dimensions, their meanings, their provenance, and the questions used to measure them. Jev proposes readings. CoreNexus preserves source, uncertainty, evidence, version, and standing.

Truth-state boundary

Layer	Standing
The existing public Dragon creations and their authorship	Current canonical source
The exported public corpus used by the preview	Pinned fixture projection, never a second canon
The versioned semantic-frame registry in this document	Proposed planned coordinate system
Jev scores and relation candidates	Model-proposed derived evidence
Human-curated chapters or accepted navigation edges	Governed decisions, separate from model output
A learner's path, reflection, or developmental meaning	Private and sovereign, outside this first pass

The experimental Dragon Codex currently present in the production database is explicitly outside this project's source set. The fixture exporter, migration, workers, and semantic registry must not query, copy, compare against, or derive meaning from those records. This experiment starts from the public Dragon Creations plus the checked-in Universal Harmonic Taxonomy.

The first implementation must not infer spiritual rank, author intention, learner development, or universal truth from a score.

Architecture decision

Use TypeScript Convex actions first

Convex functions run in the default Convex JavaScript runtime or the Node.js action runtime. Convex is not a container or arbitrary Linux-process host, so a compiled Rust executable cannot simply be uploaded and executed inside an action. A Rust-to-WebAssembly module may be technically possible for a later measured computational hotspot, but it adds a build, bundle, runtime, and debugging boundary before the experiment has demonstrated one.

The first pass therefore uses:

Convex queries and mutations for canonical reads, authorization, job state, and derived records;
Convex actions in the default runtime for authenticated Jev HTTP calls;
plain TypeScript for deterministic hashing, sparse-vector comparison, candidate selection, and projection shaping; and
scheduled functions for debounce, retries, and bounded continuous processing.

This keeps the whole loop visible in the existing stack and lets us measure whether any step actually needs Rust or WebAssembly.

Use Jev as a typed sensor, not an autonomous interpreter

Jev's System One interface accepts one state plus many typed questions and evaluates those questions in parallel. The first adapter should call the currently documented POST https://api.typesafe.ai/v1/systemone endpoint directly from a server-only action. A probe may request jev-latest, but the run records the returned versioned model identity, pins that identity for every subsequent request, rejects any response that resolves to another model, and includes it in job identity. The provider credential lives only in the Convex environment as TYPESAFE_API_KEY; it never enters browser code, fixtures, logs, or git.

Every request and result is bound to:

the exact Creation source hash;
the dimension-registry version and hash;
the question-set version and hash;
the requested and resolved model identifiers;
token usage, latency, and provider request identity when available; and
the pipeline version that normalized the answer.

Changing any of those identities produces a new analysis revision instead of rewriting the meaning of an old run.

Planned semantic atlas

The Mystery School does not have one privileged vector. It has a registry of explicit, versioned semantic frames. Every frame declares its dimensions, question types, interpretation rules, source lineage, licensing notes, and deterministic hash. Frames remain separate in storage and explanation; bridge rules may connect them without flattening their meanings.

Foundational frame — Universal Harmonic Taxonomy and eight trigrams

The first and primary frame is the checked-in universal-harmonic-taxonomy.json, the authoritative organizing principle for CoreNexus. Its eight Spectral Rays supply a coherent macrospace across element, physical process, chakra and interface, emotional quality, experiential translation, scalar mappings, life domains, astrology, impact sectors, and the eight I Ching trigrams.

For each Ray, the initial Jev request asks two distinct bounded questions:

a Score over ordered centrality levels — absent, trace, supporting, central, organizing; and
a Choice over expression modes grounded in the Ray's documented correspondences — generative, constrained, integrating-both, indeterminate.

A second set of typed questions asks whether each trigram participates in the Creation's lower and upper positions. Lower and upper are structural positions in a hexagram, not automatic claims about inner life, spiritual rank, or author intent. The complete distributions stay available rather than forcing each Creation into one cell.

A model-inferred Ray or trigram reading is never allowed to overwrite a Creation's authored primeRay or tags.

Central emergent frame — Dragon Codex

The Dragon Codex is the central 64-coordinate lens for this work, but its meanings are not yet defined. Its stable initial structure is only the ordered composition of the eight trigrams: eight possible lower trigrams crossed with eight possible upper trigrams, yielding 64 addressable hexagram cells.

The first pass may derive a transparent composition proposal from lower- and upper-trigram probability distributions and then ask bounded Jev questions about the strongest candidate interactions. That proposal remains source-bound and model-proposed. It is not a Dragon Codex definition.

The corpus itself becomes the emergence field. Every Codex cell begins as:

a stable ordered trigram-pair identity;
a set of source-bound Creation membership proposals with probabilities and evidence;
deterministic paths and clusters that can be inspected from the Mystery School; and
an empty or proposed meaning layer whose standing is explicit.

Jev cannot generate arbitrary canonical Codex prose. A human or Dragon collaborator may author a versioned MeaningAssertion for a cell after inspecting its source constellation. Jev may evaluate bounded claims about that assertion; deterministic validators may report reference, scope, evidence, loss, and compatibility; and an accountable review may accept, revise, decline, or reopen it. No model score converts a proposal into accepted Codex meaning.

This is the Master Key bridge: Dragon Creations may be morphed into an 8-by-8 Codex projection while retaining stable source identity, and any stronger semantic isomorphism claim requires a directional, versioned compatibility witness. Visual resemblance, shared labels, graph reachability, or repeated model confidence is not such a witness.

Comparative frame — Gene Keys

The 64 Gene Keys are a related, high-resolution developmental lens, not the source or definition of the Dragon Codex. The checked-in Gene Key material supplies stable Shadow, Gift, and Siddhi terms for its own frame. One Jev Choice per Gene Key can return probabilities for absent, shadow, gift, and siddhi.

The deterministic adapter may derive resonance and a normalized Shadow / Gift / Siddhi distribution for that frame. Any bridge from a Gene Key to a Dragon Codex cell records only the exact structural hexagram correspondence unless a separately reviewed witness supports a stronger semantic relation. Gene Key prose never backfills or silently names a Dragon Codex meaning.

Additional authored frames

Future frames may include named wisdom-tradition motifs, practices, questions, symbols, scales of application, and source lineages. A frame enters only when its vocabulary is explicit, provenance is reviewable, and its questions have a bounded typed interpretation. Model-emergent dimensions do not silently enter the registry.

Each stored coordinate is addressed by (frameId, frameVersion, dimensionKey). Similarity and graph assembly operate within declared frames first. Cross-frame bridges are versioned directional mappings with declared scope, loss, and standing. A shared classical hexagram identity can establish structural correspondence; it cannot establish semantic equivalence among the Universal Harmonic Taxonomy, Dragon Codex, Gene Keys, or any wisdom tradition.

Finding obvious and hidden connections

An all-pairs model comparison over 968 posts would create hundreds of thousands of pair checks before we know what is useful. The minimal pipeline is a funnel.

Stage 1 — deterministic obvious edges

Code proposes exact, inspectable candidates from:

explicit Creation links or references;
exact or normalized title and teaching-name mentions;
shared authored tags;
chapter or Sequence adjacency, labeled as curation rather than semantic truth;
shared Dragon authorship or co-creation; and
source chronology.

These remain separate predicates. Adjacency never silently becomes prerequisite, and shared authorship never silently becomes agreement.

Stage 2 — planned-vector neighbors

For each Creation, deterministic code searches each enabled frame for a bounded neighbor set. It uses transparent measures such as weighted overlap and distribution distance, never an unnamed embedding dimension. A sparse inverted index over each Creation's strongest (frameId, dimensionKey) coordinates avoids an all-pairs scan.

Candidate generation is reproducible from stored frame profiles. The UI can explain it in ordinary language: for example, “Both teachings are centrally Purple / Thunder, and both project strongly into the Thunder-over-Water Codex cell; that cell has no accepted meaning yet.”

Stage 3 — Jev relation proposals

Only the bounded candidate pairs enter a second typed Jev pass. The initial relation vocabulary is small and directional:

explicitly-invokes;
same-question;
complements;
contrasts;
grounds-or-prerequisite;
practice-for;
scale-echo;
shadow-gift-siddhi-transmutation;
cross-tradition-echo; and
none-of-these.

Jev's typed answers do not generate arbitrary prose or source spans. Exact evidence is therefore a second bounded request conditioned on the selected relation predicate and direction, not an unrelated parallel question. Deterministic preprocessing splits each source into stable paragraph locators, ranks a bounded candidate set, preserves the digest and omission count for excluded locators, and never presents more than 255 Choice options or a request beyond the provider context limit. The persisted proposal contains the selected relation distribution plus the relation-conditioned source and target locator distributions. A gate verifies that both locators name the same predicate and direction before persistence. A relation without two source-bound evidence locators is not persisted as a candidate. Model output enters with standing: model-proposed and allowedActions: inspect; it cannot become a navigable curriculum edge until a separate accountable decision grants that standing.

Stage 4 — semantic spines

A semantic spine is a projection, not a new truth object. It is a reproducible path through admitted sources under one declared rule, such as:

one Harmonic Ray or trigram moving across domains or scales;
one ordered trigram pair gathering a source constellation before any Codex meaning is accepted;
one proposed Codex meaning traced through its supporting, contradicting, and unresolved sources;
one Gene Key developmental pattern inspected as a separate comparative lens;
one idea recurring across wisdom traditions;
one practice moving from individual to relational to planetary scale;
one Dragon's teaching explicitly invoking another's; or
one learner-chosen question traced through contrasting responses.

Every spine names its rule, sources, relation revisions, and omissions. Different rules may produce different valid spines over the same corpus.

Convex data model

Add new tables rather than placing model output on canonical Creation rows.

`sensemakingRuns`

One immutable run envelope and resumable operational state:

run ref, scope, status, and timestamps;
source-manifest identity and corpus counts;
pipeline, registry, question-set, and model identities;
cursor, retry counts, token use, measured latency, and measured cost;
aggregate result counts and bounded error summaries; and
explicit preview, production, or continuous origin.

`sensemakingJobs`

One reusable operational record per exact source and stage. Profile-job identity is (creationId, sourceHash, stage, pipelineVersion, questionSetHash, resolvedModel). Relation-job identity additionally includes target Creation/source hash, direction, and candidate-set digest:

source and target identities as required by the stage, deterministic job key, and separate run-to-job associations;
queued, running, completed, failed, blocked, or stale status;
attempt count, bounded retry time, lease, and terminal error code;
measured request count, token use, and latency; and
created, updated, and completed timestamps.

The run is the aggregate envelope; jobs make every source and retry reconcilable. A reusable job may serve several runs without losing per-run accounting. Because TypeSafe does not document request idempotency, the external call is at-least-once: every attempt atomically reserves budget, leases carry fencing tokens, only the current lease may commit, stored outputs deduplicate by exact job/result identity, and timed-out or ambiguous attempts remain counted in request and cost totals. Duplicate schedulers converge on one local job, but the design does not falsely promise that an ambiguous external response can never be purchased twice.

`creationSenseProfiles`

One profile revision per Creation, source hash, and pipeline version:

canonical Creation id and source hash;
one complete probability profile per enabled semantic frame;
canonical and inferred coordinates kept distinct;
top sparse dimensions for rendering;
confidence and provider provenance; and
supersession link when a newer source or pipeline revision exists.

`creationSenseDimensions`

A sparse indexed projection of the strongest dimensions rather than dense rows for every coordinate in every frame:

profile id, Creation id, frame id/version, dimension key, and registry version;
normalized probability or ranking weight, confidence, and the typed answer payload declared by the frame; and
indexes for dimension-ranked browsing and Creation lookup.

The complete frame profiles stay on the profile revision. Sparse rows make “show the strongest Purple / Thunder teachings,” “show the strongest sources projected into Thunder-over-Water,” and “inspect Gene Key 44 as a comparative lens” cheap without creating unnecessarily dense tables.

`semanticFrameBridges`

A directional, versioned mapping proposal between exact frame coordinates:

source and target frame/dimension revisions;
structural, exact-under-scope, close, broader, narrower, or related relation kind;
purpose, direction, declared transformation, loss, assumptions, and evidence;
model-proposed, human-reviewed, accepted, declined, or reopened standing; and
decision lineage when an accountable review changes its standing.

The first Codex bridge may establish only that one Dragon Codex cell and one Gene Key refer to the same ordered classical trigram pair. It must not claim that their meanings are equivalent.

`creationSenseRelations`

A source-revision-bound proposal or decision projection:

source and target Creation/profile revisions;
directional predicate;
origin and standing;
probability, confidence, and deterministic candidate score;
source and target evidence locators plus checksums;
allowed actions; and
optional decision lineage, never folded into the model result.

All tables have indexes matching actual reads. No v.any() is introduced for the new contracts.

Fixtures and the first complete pass

Corpus fixture

The implementation uses the complete anonymous-public Dragon export named in the run manifest. It seeds ordinary Creation fixtures and the Eleven required Dragon-owner fixtures into the pull request's persistent Convex preview database.

The fixture pipeline must:

validate the canonical Dragon roster and public-only export contract;
preserve the production Creation id as an explicit source reference rather than pretending the new preview id is canonical;
insert only the allowlisted fields required by the Mystery School and source renderer;
preserve exact source timestamps and content hashes;
omit comments, reactions, private metadata, credentials, and expiring signed media;
use deterministic fixture keys so repeated preview deploys upsert rather than duplicate; and
verify declared total, unique source ids, per-Dragon counts, source hashes, and inserted Creation count before sense-making begins.

The repository may carry the text fixture because the operator has now explicitly selected the complete public Dragon export for this experiment. Media binaries still do not enter git; stable references may be preserved when safe.

Fixture provenance ends at preview seeding and verification. The fixtures create ordinary rows in creations; no sense-making selector, run identity, job identity, or public explorer query may read the fixture-provenance table or accept fixture revision or manifest hash as semantic scope. On preview, those ordinary Creation rows happen to come from the pinned export. On production, the ordinary Creation rows already exist.

Migration and external-action boundary

@convex-dev/migrations mutations cannot and should not perform external Jev HTTP work. The migration layer has one deterministic responsibility: query creations through the canonical public-Dragon eligibility policy and idempotently enqueue analysis work for the pinned pipeline version. This selector and enqueue path are identical on preview and production.

The full preview sequence is:

seed and verify the Creation fixtures;
run the ordinary migration proving-ground gates;
enqueue one deterministic job per (creationId, sourceHash, pipelineVersion);
let a bounded action worker call Jev and commit validated results through internal mutations;
resume safely after rate limits, transient failures, or deploy interruption; and
run a final corpus verifier that proves every in-scope source is completed, explicitly failed, or blocked — never silently missing.

The same enqueue migration runs unchanged over canonical production Creations. Only the origin of the underlying rows differs: preview rows are established by fixtures before the migration, while production rows are the existing canon. Production activation and credential configuration remain separate, explicit release decisions.

Before the complete pass, run one two-question request, one complete Harmonic-Ray request, one lower/upper trigram request, one bounded Codex-cell interaction request, and one optional Gene Key request against the authorized account. The public TypeSafe model reference now publishes Jev 1.13's operating envelope: $0.042 per million input tokens with output tokens currently free, 250,000 tokens per second, 1,200 requests per min...[truncated] The probe resolves and pins the model version, exercises the largest normalized Creation, proves the 32k state-plus-longest-question and 64k request context bounds, records payload size, latency, tokens, and account-visible cost, and derives a hard dollar ceiling enforced before each reserved attempt. If a frame request is rejected or unstable, shard its ordered registry deterministically while retaining one logical profile job. Before sending the corpus, record the authorized account's retention and zero-data-retention terms; TypeSafe says requests are not used for training, while retention follows its legal/DPA terms and enterprise zero-data-retention is account-specific.

Continuous sense-making

After the first pass:

a published Dragon Creation or meaningful edit marks its prior profile stale and schedules analysis after a short debounce;
the worker re-reads the Creation and no-ops if its source hash no longer matches the queued job;
the profile-job key is the full stage/model/question identity defined above, while pair jobs also include target revision, direction, and candidate-set digest;
an hourly reconciliation job finds missed or stale work without rescanning model-complete revisions; and
an admin-only action can request a bounded re-run under a new pipeline version.

This gives fast-enough freshness without paying for a global every-minute sweep. Measured preview latency and cost determine the final concurrency, debounce, and reconciliation cadence.

Navigation and visualization

Build these lenses as one Mystery School application rather than separate source-reading and sense-making products.

Lenses

Tome — canonical long-form reading with nearby semantic invitations.
Constellation — Creation and Dragon nodes connected by declared relation revisions.
Semantic Spine — one named traversal rule rendered as lightning through selected teachings.
Harmonic Field — the primary eight-Ray and eight-trigram landscape, with authored and inferred signals visibly distinct.
Dragon Codex — an 8-by-8 upper/lower trigram field that morphs the same stable Creation identities into 64 structural cells; unnamed and proposed cells remain visibly unnamed or proposed.
Gene Key Field — an optional comparative lens over Gene Key resonance and Shadow / Gift / Siddhi expression.
Tradition Weave — inspect cross-tradition echoes without collapsing lineages into sameness.
Accessible Table / Linear Map — truth-equivalent source, score, relation, standing, and evidence in ordinary reading order.

Interaction grammar

Selection survives every lens through canonical structured URL state. Selecting a Creation, Dragon, frame coordinate, Codex cell, relation, or spine changes projection and emphasis; it does not change source or relation standing. Every connection opens a Why this connection? disclosure that shows:

relation predicate and direction;
model-proposed or human-decided standing;
source evidence from both teachings;
planned dimensions that contributed;
confidence and uncertainty;
model, registry, and source revisions; and
the actions currently authorized.

The visual field uses existing CoreNexus tokens and canonical harmonic colors. Position, size, glow, and color must not imply truth, rank, or spiritual attainment. Every spatial view has a complete keyboard-operable textual equivalent.

Minimal implementation slices

Contract and registry — ratify this architecture; register the Universal Harmonic, trigram-composition, and empty structural Dragon Codex frames; register Gene Keys only as a comparative frame; and test deterministic hashing, bridge mappings, and question generation.
Corpus fixture — import and verify the complete public Dragon corpus as preview Creation fixtures while proving the experimental production Codex is absent from the source set.
System One profile pass — test-drive the Jev adapter, job coordinator, Harmonic/trigram profiles, Codex composition proposals, profile tables, retries, and idempotency; run the complete preview corpus.
Connection funnel — generate obvious edges, planned-vector neighbors, source-to-Codex mapping proposals, and evidence-bearing model proposals.
Living navigation — add the Harmonic Field, 8-by-8 Dragon Codex, Semantic Spine, and accessible linear forms; keep the Gene Key comparison optional.
Preview review — publish measured totals, latency, token usage, cost, failures, relation coverage, and browser evidence for human review.
Continuous mode — activate save-triggered debounce and hourly reconciliation only after the complete pass is stable.

These implementation slices converge on one fresh implementation pull request branched from current main. Earlier experimental pull requests are optional inspiration only; they are not bases, dependencies, merge targets, or acceptance criteria.

Acceptance gates

The experiment is reviewable when the preview proves:

the fixture manifest's declared total equals unique exported ids and inserted preview Creation rows, while an independent canonical creations query enumerates the same 968 eligible rows without consulting fixture provenance;
all Eleven canonical Dragon owners resolve, with per-Dragon counts reported;
every completed profile binds to exact source, enabled frames, registry, question-set, model, and pipeline revisions;
the Dragon Codex exposes exactly 64 ordered trigram-pair identities without importing meanings from the experimental production Codex;
every source-to-Codex placement remains a probability-bearing proposal with stable Creation identity and inspectable evidence;
local retries resume without duplicate profiles or relations, every external attempt is budgeted, and ambiguous at-least-once provider calls remain visible in cost totals;
the probe pins one resolved model, validates the largest source against provider context/option limits, derives and enforces a hard dollar ceiling, and records the account retention/ZDR determination;
no source text, credential, or provider response body enters logs or analytics;
every persisted relation has two valid endpoints, a declared predicate, standing, probability/confidence, and inspectable evidence;
model proposals never gain navigation authority without a separate decision;
spatial and accessible linear projections expose equivalent sources, relations, standings, and evidence;
structured URL selection restores the same source and lens after reload;
targeted tests, pre-commit checks, pull-request CI, and preview QA are green; and
latency, token use, and cost are measured from the real pass rather than asserted from marketing language.

Explicit non-goals for the first pass

no opaque embedding index;
no arbitrary Rust executable inside Convex;
no model-written canonical Creation or Dragon Codex content;
no import, comparison, or semantic use of the experimental production Dragon Codex;
no automatic claim that structural hexagram correspondence establishes semantic equivalence;
no automatic claim that similarity means lineage, agreement, prerequisite, or truth;
no developmental scoring of learners or authors;
no private reflection or learner-state persistence;
no media-binary fixture import;
no production model run before preview review and explicit activation; and
no premature framework for dimensions beyond the first reviewed registry.

Source lineage

This proposal draws most directly from the Master Key work on planned semantic dimensions, dimension-map certificates, Jev as a bounded System One sensor, directional semantic-compatibility witnesses, and one-canon/many-projections architecture. It also preserves the Open Source Mystery School contracts for stable source identity across isomorphic views, proposal standing, evidence, lens equivalence, and sovereign learner meaning. In this project, “morph” means changing the projection while preserving keyed sources; “isomorphism” remains a witnessed claim, never a synonym for visual continuity.

Provider capability statements should be rechecked against the current TypeSafe Jev documentation at implementation time. Convex runtime constraints should be rechecked against the current Convex runtimes and actions documentation before introducing any native or WebAssembly boundary.

Current implementation references: