Companion guide
Companion to the internal state-of-framework site. No prior technical background assumed.
This document walks through every term and concept on the internal site. Read it once, end to end, and the site stops being engineer-speak and starts being strategy. The framework comes down to a single bet. We are building a knowledge base of the structural position of every company in every market we cover, growing it weekly, and using it to power three things — stack rankings, weekly intelligence briefs, and the customer-facing brand dashboard. The knowledge base is the asset; the reports are how we prove it works.
Imagine the ShurIQ system as a three-layer building.
The business thesis is that the basement is the moat. The reports demonstrate the moat exists. Within the next 18 to 24 months, the basement will hold roughly a billion facts and become an asset in its own right — an infrastructure asset rather than a service business.
That picture is what every term on the internal website is naming.
The site uses words like “RDF triples,” “ontology,” “SPARQL,” “named graph,” “DecayMetric.” These are real technical terms with specific meanings — and each one has a plain-language translation. Here is the full dictionary.
A way of storing information that focuses on how things connect, not just what they are.
A spreadsheet stores rows: each row is one thing, each column is one fact about it. A knowledge graph stores relationships as first-class things. Instead of saying “ReelShort has a composite score of 84.2 in column F,” a knowledge graph says “ReelShort — was-scored-at — 84.2 — for-week — W19-2026 — in-vertical — micro-drama.” Each link is a fact in its own right.
Why knowledge graph instead of spreadsheet? Because we have to answer questions like “which platform giant moved more than 5 points across the last six weeks” — questions that span time, dimensions, and relationships. Spreadsheets can do this with a lot of formula gymnastics. Knowledge graphs do this directly because the relationships are what they store.
The smallest unit of information in our knowledge graph. Each one is a sentence with three parts: Subject — Predicate — Object.
Like:
When you see “91,278 triples” or “103,294 triples” on the site, that is the count of facts in our knowledge base. Every score, every relationship, every metadata field is one of these. They add up fast.
The dictionary that defines what kinds of things we track and how they connect.
Think of an ontology as the rulebook for the basement. It says: “we track Companies, ScoreRecords, Dimensions, Verticals, Weeks. A Company has-a-ScoreRecord-for-a-Week. A ScoreRecord has-five-DimensionScores. A DimensionScore is-for-one-Dimension.”
Without an ontology, the basement is a pile of facts in random formats. With it, every fact follows a known shape, and we can query the basement by asking “give me every Company with a ScoreRecord above 70 in any Week” — a question that only makes sense because the ontology defines those terms.
We have two ontologies today: one for the AI-agent vertical (ai-agent-sbpi) and one for the micro-drama vertical (micro-drama-sbpi). They share a common base ontology that defines the universal pieces. Each vertical adds its own five dimensions on top.
The language we use to ask the knowledge graph questions.
If knowledge graph is the database and ontology is the dictionary, SPARQL is the question language. You hand it a question like “list the top 10 companies by composite score” and it returns the answer. Every chart on the viz hub is powered by a SPARQL query running against the live knowledge base.
You do not need to learn SPARQL to use the system. The viz hub writes the queries; you read the results.
A way of organizing the knowledge base into labeled sections.
If the knowledge base is a filing cabinet, named graphs are the folders. We have a folder for AI-agent W12 scores, a folder for micro-drama W10 scores, a folder for micro-drama W19 scores, and so on. The folders share the same filing system (the ontology) but keep their contents separate.
This lets us answer questions like “show me only what changed in W19” or “compare AI-agent and micro-drama for the same week” without the data mixing in confusing ways.
When the site says “named graph https://shurai.com/graphs/derived/decay/micro-drama,” that is the label of the folder where we keep the decay calculations for the micro-drama vertical. The URL is just the folder’s name — nothing about it lives online; it is a globally unique label.
Three different software tools that store and query knowledge graphs.
GraphDB is what we run today — a desktop application that holds our knowledge base on Jonny’s machine at port 7200. Oxigraph is a competing tool we used earlier in the project. Rdflib is a Python library that holds knowledge graphs in memory for testing.
Why three? Because we built the system to be portable. Same data, same questions, same answers — different software underneath. If GraphDB stops working for us, we can switch to one of the alternatives in an afternoon. The internal site has a viewport showing this portability proof.
Think of it like Microsoft Word, Google Docs, and Apple Pages all opening the same .docx file. Different programs, same file. The file is what matters.
Our five-dimension scoring system. Every company we track gets five scores between 0 and 100, plus a weighted composite of those five.
The five dimensions are vertical-specific. For micro-drama:
For AI agents:
Different verticals have different dimensions because different industries compete on different things. The framework is the same. The vocabulary changes.
The weighted average of the five dimension scores for a single company in a single week. A number between 0 and 100. On the site, when you see “ReelShort 84.2” or “Persana AI 69,” that is the composite.
Composites are how we stack-rank companies within a vertical.
An industry segment we cover. Today’s verticals: AI agents and micro-drama. Other defined-but-not-yet-ingested verticals: nonprofit, tech, consumer, healthcare, media.
A vertical brings its own dimension definitions, its own competitor set, and its own update cadence. The structural framework (companies, ScoreRecords, etc.) is shared across all verticals.
One scoring event. A single company, a single week, five dimension scores, a composite, and an attestation chain pointing back at the sources that supported the scoring.
When the site says “1,672 ScoreRecord instances” it means we have 1,672 such scoring events captured for the AI-agent vertical — one for each of the 1,672 companies in W12. When it says “21 companies × 10 weeks = 210 ScoreRecord instances” for micro-drama, that is 21 companies scored across 10 weekly cycles.
One of the five sub-scores inside a ScoreRecord. There are five DimensionScores per ScoreRecord — one for each dimension. So 1,672 ScoreRecords × 5 = 8,360 DimensionScore instances for AI-agent.
The audit trail. Every score we record carries a provenance chain that traces back to the evidence we used. PROV-O is the standard format we use to store that chain. It is the “show your work” layer of the knowledge base.
When you see “1,672 Attestation instances” on the site, that is the count of audit trails — one per ScoreRecord.
How fast the structural rankings shift in a vertical.
Some markets move slowly. The big platforms keep their position week after week. Other markets move fast — a deploy or a press cycle reshuffles the top 10. λ is the number that captures this.
We measure λ by looking at how much each company’s composite score changed between two weeks, taking the absolute value of that change (so a +2 move and a -2 move count the same), and then taking the median across the whole vertical for the week. The result is a single number that tells us how active the vertical was that week.
For micro-drama, λ peaked at 1.85 in W12 (a turbulent reporting week) and dropped to 0.00 by W17–W18 (the cohort settled). It nudged back up to 0.10 in W19 when Amazon Prime Video Clips deployed.
λ matters strategically because it determines our refresh cadence. A vertical with high λ needs nightly updates; a vertical with low λ can hold for a week or more without going stale. It also matters competitively — a market that decays fast means the competitor who starts later starts with an empty database. Slow-decaying markets are less defensible.
A record of how much one company moved between two consecutive weeks. The data structure for λ.
For each company, for each pair of consecutive weeks we have scores in, we generate one DecayMetric instance. It captures: which company, which fromWeek and toWeek, what was the composite delta, what is the annualized decay rate (delta × 52, so a +1 move per week implies +52 per year), and what is the rolling 4-week volatility around that point.
For micro-drama: 21 companies × 9 week-pairs = 180 DecayMetric instances (the site mentions this number).
The summary of all DecayMetric instances for one vertical at one week.
It aggregates the 21 DecayMetrics for the week into a single record with: the median λ, the mean λ, the p90 λ (the 90th percentile — captures the tail of volatility), and the sample size.
For micro-drama: 9 LambdaSnapshots (one for each week with a previous week to compare against).
A part of the customer brand dashboard that frames a company’s structural position using the math of stability dynamics.
The name comes from the Russian mathematician Aleksandr Lyapunov, who studied how systems return to (or fly away from) equilibrium after a shock. The idea translated to brand analysis: every company has a “basin” — a stable structural position it tends to occupy. Shocks pull it away from the basin. The question is whether the company is being pulled deeper into a stable basin (high basin grip) or wandering away from any stable position (low basin grip).
Today the Lyapunov layer in the brand dashboard runs on hand-curated numbers. After Line 2, it will run on numbers derived from the DecayMetric pipeline — same visual, principled source.
Two technical phrases that mean the same simple thing.
The brand dashboard reads a file called state/current.json to draw its visualizations. Today, a human (Jonny, mostly) writes that file by hand each week. We are replacing that with a script that reads the knowledge base and writes the same file shape automatically. The dashboard sees no change. The work behind the dashboard changes from “person types numbers” to “script reads graph and outputs numbers.”
“Wire the dashboard’s daily snapshot to the export path” means: hook up the dashboard’s input file to be produced by the script, not by hand. Once wired, every change in the knowledge base flows to the dashboard automatically every night.
The four measurable claims behind the ShurIQ business case.
Loading historical data we already have into the knowledge base.
When the site says “10-week backfill,” it means we took 10 already-existing weekly score files from the vault archive and loaded them into the knowledge base. Backfill is one-time work — once the past is in, future weeks add incrementally.
When we calculate a company’s composite score, we multiply each dimension score by a weight, then add them up. The weights are different for each vertical, because what matters in micro-drama is different from what matters in AI agents.
For micro-drama, distribution gets 30% weight (it matters most), content and community get 20% each, narrative and monetization get 15% each. The weights live in a methodology document, not in the ontology — that is intentional, so we can tune them without changing the schema.
You will see “D — A — E — λ” treated as if they are a quartet. Here is what each one is asking, in one sentence.
| Variable | The question it asks | Where we stand |
|---|---|---|
| D — Node Density | How big is the asset? | 105,738 facts. Within the next 18-24 months: 1 billion. |
| A — Ontological Alpha | Is our worldview original? | Yes, for both verticals tracked. No public equivalent exists. |
| E — Extraction Efficiency | Can we grow without revenue? | Modeled yes ($7/cycle), not currently running as a standing job. |
| λ — Decay Rate | How fast does the market change? | Now measurable for micro-drama. Settled from 1.85 (W12) to 0.10 (W19). |
D and A are size and originality of the moat. E says the moat grows on its own. λ says the moat is defensible because nobody can catch up to ten weeks of history overnight.
The state-of-framework editorial said the work breaks into three lines. Two of them shipped on 2026-05-15. Here is what each line is, what we did, and what is left.
Before this line, our weekly scoring lived in a JSON file that humans edited by hand. Some of that data also lived in the knowledge base. Two truths, no single source of record. We were managing two versions of the same scores.
We built a small Python library called shuriq-kg that does three things:
Then we used the library to load all 10 weeks of historical micro-drama scoring (W10 through W19, 2026) into the knowledge base in one run. The knowledge base went from 91,278 facts to 103,294 — a 13% increase.
The knowledge base is now the source of truth for micro-drama scoring. Every analysis we do can hit the same data. Cross-vertical comparison (AI-agent vs. micro-drama) is now a single query away because both verticals share the same basement.
The dashboard still reads the hand-curated JSON, not a script-generated one. Wiring the dashboard to the script is operational work, covered in Part 5 below.
We claimed λ as one of our four thesis variables. We had no way to measure it. Without multi-week history in the knowledge base, the math was not possible. The internal site, the pitch deck, and the editorial briefs all referenced λ as if it existed, but it did not.
Now that 10 weeks of micro-drama scoring sit in the knowledge base, we wrote code that:
For micro-drama, this produced 180 DecayMetric instances and 9 LambdaSnapshots. They live in their own labeled section of the knowledge base, derived from but separate from the source scoring data, so we can recompute them anytime without disturbing the original scores.
| Week | Median λ | Story |
|---|---|---|
| W11-2026 | 0.90 | Cohort tracking expanding (16 companies → 17) |
| W12-2026 | 1.85 | Peak volatility — reporting cadence still finding rhythm |
| W13-2026 | 1.25 | Mid-volatility as new entrants enter |
| W14-2026 | 0.60 | Cohort settling |
| W15-2026 | 0.30 | Continued settling |
| W16-2026 | 0.20 | Continued settling |
| W17-2026 | 0.00 | Structural floor — no median movement |
| W18-2026 | 0.00 | Continued floor |
| W19-2026 | 0.10 | Nudges up on Amazon Prime Video Clips deploy |
What the numbers say: the cohort started volatile (because our reporting was new and we were still calibrating), found structural stability around W17, and the Amazon deploy in W19 was big enough to register as movement.
| Company | Net composite change |
|---|---|
| JioHotstar | +16.80 |
| COL Group / BeLive | +14.45 |
| GoodShort | +6.40 |
| Disney | +6.20 |
| DramaBox | +6.05 |
| Lifetime / A+E | +5.90 |
| Amazon | +3.55 |
These are the brands whose structural position moved the most across the tracked period.
λ is no longer an unmeasured promise. We can quote it in the pitch. We can use it to set refresh cadences per vertical. The Lyapunov layer in the brand dashboard can now read from this derived data instead of from numbers Jonny enters by hand.
The brand dashboard still reads the hand-rolled Lyapunov inputs. Wiring it to read from the DecayMetric pipeline is a small follow-up — same visual, principled source.
ShurIQ’s name comes from Doug Engelbart’s 1962 paper Augmenting Human Intellect — the idea that the right instrument can make a group think better together. That framing is implicit in our private notes and pitch drafts. It is missing from our customer-facing surfaces, the investor deck, and the explainer.
One or two sentences that name this framing, threaded into the lead paragraph of every customer-facing artifact. The work is voice, not engineering. Jonny owns the line.
This phrase is one of the highest-leverage operational items in the framework. It is also the most mechanical. Here is what it actually means and how we get there.
The customer-facing brand dashboard at shuriq-brand-dashboards.pages.dev reads a file called state/current.json to render its visualizations. That file is written by hand each week. Jonny opens it, edits the scores, edits the composite, edits the deltas, edits the rationales, saves it, and the dashboard picks up the new file at the next deploy.
The same state/current.json file gets regenerated automatically every night by a script. The script reads the latest scores from the knowledge base, formats them in the same JSON shape the dashboard expects, and writes the file. The dashboard sees no change in what it reads or how it reads it. The change is entirely upstream.
We could wire this once per week. Daily is the better cadence for two reasons. First, the auto-research pipeline (Line 1’s auto-research cycle, when it runs) emits new signals daily — the dashboard should reflect those. Second, the editorial cadence is weekly but the dashboard is meant to feel current, so giving it a daily refresh tightens the loop between research and presentation.
shuriq_kg.cli export command already does the heavy lifting — it queries the knowledge base and writes a state JSON file. We package that as a single Python entry point that takes no arguments and writes to a known path..plist file in ~/Library/LaunchAgents/ tells macOS to run the script every night at, say, 3 a.m. We log its output to a file we can check.state/current.json lives in the vault at projects/microco/competitive-intel/state/current.json. The brand dashboard reads from projects/shur/shuriq-brand-dashboard-gateway/state/.... We need to settle which file is canonical and have the script write to that path.For an MVP that runs on Jonny’s machine and updates one vertical: half a day of work. The export logic already exists. The wiring is launchd, file paths, and a single deployment trigger. Verification is the most careful part — we want to be confident the dashboard sees what we expect before turning off the manual workflow.
For a production-grade version that runs in the cloud, monitors itself, and handles failure gracefully: a couple of days.
The framework is one system, even though the website talks about its parts separately. Here is the picture in one paragraph.
We research companies in a vertical each week. We score them on five dimensions per the SBPI methodology. The scores get written to state/current.json and (after Line 1) automatically loaded into the knowledge base. The knowledge base now holds every weekly snapshot we have ever produced. From that history, we derive the DecayMetric records that track how each company moves week to week, and we aggregate those into LambdaSnapshots that summarize the volatility of each vertical. The Lyapunov layer in the brand dashboard reads from those derived records and frames each company’s structural position. The editorial briefs read from the same data and tell the strategic story. The stack ranking on the public website is a different view of the same underlying scores.
Everything points at the same basement.
The other open item. This one is shorter.
The AI-agent vertical has 1,672 companies but only one week of scores (W12-2026). The micro-drama vertical has 21 companies but 10 weeks. To measure λ for the AI-agent vertical, we need at least two consecutive weeks. To make λ reliable, we need at least four.
The work: run the AI-agent scoring auto-research for W13, W14, W15 and onward. The methodology is already locked. The pipeline already exists. What is missing is execution — running it, reviewing the output, and ingesting each week into the knowledge base.
Whoever owns the auto-research cycle (or a process where we run it manually each week until automated) takes this on. Each weekly cycle for the AI-agent vertical should produce another ScoreRecord per company. After four weeks, λ for that vertical is meaningful.
For quick reference. The full definitions live in Part 2 above.
| Term | One-line plain language |
|---|---|
| Knowledge graph | A database that stores how things connect, not just what they are |
| RDF triple | One fact: Subject — Predicate — Object |
| Ontology | The dictionary that defines what types of things we track |
| SPARQL | The language for asking the database questions |
| Named graph | A labeled section of the database |
| GraphDB / Oxigraph / rdflib | Three software tools that can hold our knowledge graph |
| SBPI | Our five-dimension scoring system |
| Vertical | An industry we cover |
| ScoreRecord | One scoring event: company × week × five dimensions |
| DimensionScore | One of the five sub-scores within a ScoreRecord |
| Composite score | Weighted average of the five dimensions, 0-100 |
| Attestation / PROV-O | The audit trail behind every score |
| λ (lambda) | How fast a vertical’s rankings shift |
| DecayMetric | One company’s movement between two weeks |
| LambdaSnapshot | One vertical’s aggregate movement for a week |
| Lyapunov layer | The stability-dynamics frame in the brand dashboard |
| Hand-rolled JSON | A file written by a person rather than by a script |
| Export path | The pipeline from knowledge base to dashboard input file |
| Backfill | Loading historical data we already have |
| Vertical-applied weights | Dimension weights tuned per vertical |
| D / A / E / λ | Node density / Ontological alpha / Extraction efficiency / Decay rate |