Where we stand, how Kartora stands on Nervur, what Nervur still has to bring, and who does what.
It doesn't matter who owns the browser, because everything of value comes through relations the child can't create. Agreed A browser organism at kartora.org is a stranger until the family gives it an invitation. Kartora answers it only through a relation based on the parent's. The child can't get an invitation for themselves.
Kartora knows its customer, the parent, and the family's standing. The family's organism, on a server or an edge, is the stable ground: it declares the children and keeps their profiles and data. Agreed
A wiped or lost browser gets a new invitation from the family. When a subscription ends, Kartora drops the relations and kartora.org no longer knows the family, who keep their own organism and their data. Agreed
The browser sends results to the family at the end of each session by a letter, and the family's organism is backed up to solid ground under a key the parent holds (MEM-12, KEY-10). Proposed
The promise. Kartora doesn't keep children's names, emails, addresses or other details it doesn't need. It does see what it needs to run the service, such as which chapters are asked for and how checks go. It never promises complete privacy. Agreed
For Kartora to give a family's child a relation, Nervur already has the rule: an occupant may ask a lobe, over its standing, for an invitation for another organism of its owner's, and the lobe notes it as it chooses (QUO-6).
Arrows point from the side that asks to the side that answers. In Nervur a relation runs one way, from the side that accepted to the side that invited (NODE-5).
All faculties are Kartora's own, in a repo kartora, published under org.kartora.*. Everything an author can do is an ask, so the parent's AI and a hosted model use the same methods.
| Lobe | Lives on | Holds | Main asks |
|---|---|---|---|
family | Edge | Knobs, the education country among them, approvals, budget. Raises child lobes as its children (BRAIN-7). | setKnob, approve, addChild, inviteViewer |
child | Edge | One per child. The family's record of that child: the map, evidence, requests, logs, and the child's part of every template (interests, colours, names, how they like to start). Sends sessions down and takes results. | next, results, request, map, likes, log |
player | Child's browser | One per child. The shelf and the session being played. Draws the child's pages and works offline. | shelf, open, answer, request |
author | Edge | The queue of requests and which author takes which job. | pending, take, submit |
model | Edge | Skin lobe of network: the provider's key and quota. Never named outside itself. | turn, job, stop |
graph | Edge | Reads chapters from Kartora over the family's relation, and works out the frontier from the map. | chapter, relations, frontier, templates, release |
outbox | Edge | The allowlist of fields, and a log the parent can read. Sends only fixed fields. | outgoing, sent |
view | Edge | One per receiver. Its note says who and what they may see. | colours, progress |
| repo lobe | Kartora | The repo: code, graph files, designs, website. Commits and tags are the releases. | Standard nervur.repo |
graph (Kartora's) | Kartora | Serves the current release, read from the repo's tags: chapters, lenses and templates, and the public catalogue at kartora.org. | chapter, chapters, relations, lens, templates, release |
check | Kartora | Check questions and answers. Scores metadata. | question, score |
studies | Kartora | Consented studies and their results. | join, report |
signup | Kartora | Payment events and invitations. | Invitation factory (CASE-17) |
The graph's files live in Kartora's repo, so supervisors review changes as commits, and a tag is a release. The release holds three kinds of data: the chapters, the lenses and the templates. Its public face is the catalogue at kartora.org: every subject, chapter, point, misconception and relation, through any lens, and every template with its three parts, harness and examples, so parents and teachers can verify what a child learns. Agreed
Check questions and their answers stay private, at Kartora, so they keep their meaning. Authors read chapters and templates over the family's relation. Agreed
What a subscription pays for is the service, not secrecy: kartora.org and the player, sessions prepared for each child, the private checks and colours, and new releases. Proposed
The price is that Kartora sees which chapters a family asks for. That's the same kind of metadata already accepted. A session already written carries what it needs, so play still works offline.
A session is one object: id, release, lens, chapters, steps, and who wrote it (author, model). Each step names a template and its version, then fills its three parts: the chapter's points and check it carries (Kartora's), the knobs it read (the parent's), and its slots, the world, names, colour and pictures (the child's). It also names the next step for each outcome. It's checked against each template's harness before it reaches the shelf.
A template is one object in the release: id, version, its kind (present, practise, check, quest), the knowledge shapes it can carry, how it measures, the knobs it reads, the slots the child's part fills, the blocks the player draws it with, and its harness: the brief for the AI and the rules code checks. Proposed
The player draws a small set of blocks: text, picture, bars, a number line, a slider, choices, groups to drag into, a timeline, an answer box. A new template made of existing blocks is only data, so a release brings it to every family. A new block needs a new player version. Either way the browser gets screen data, never code from a model (SCREEN-2). Proposed
| # | Asker | Answerer | Kind | How it forms | How it ends |
|---|---|---|---|---|---|
| R1 | Parent (local) | Edge brain | Owner, the anchor | Pilot fetches the first invitation by the claim (HOST-9) | Only by passing on (OWN-7) |
| R2 | Second parent | Edge brain | Owner | invite by a parent | drop |
| R2b | Parent's browser at kartora.org | Edge brain, or family lobe | Owner, or a narrower relation. Open | An invitation from a parent's organism, opened at kartora.org | drop |
| R3 | player | child lobe | Sessions down, results up | An invitation from the family, opened at kartora.org (QUO-6, CASE-2) | Parent's drop. A lost browser gets a new invitation. |
| R3k | player | Kartora's lobe | What Kartora serves a child, based on the family's relation | The family asks Kartora over R4 for an invitation for its child (QUO-6) | Ends with the family's subscription |
| R4 | Edge library | Kartora repo lobe | Library's standing | signup sends an invitation after payment, and the parent's accept takes it | Its span, renewed while paid |
| R4g | Family's graph | Kartora's graph | The family's subscription: chapters on request | Invitation from signup after payment | Ends with the subscription, with every relation based on it |
| R5 | outbox | check lobe | Metadata in, colour out. One per child. Proposed | Parent's knob. A fresh ward, unlinked by address from R4 and from siblings' R5 (ORG-4). | Parent turns it off |
| R6 | outbox | studies lobe | A study | Parent's consent, one per study | Study's span, or the parent |
| R7 | Teacher's organism | view lobe | Belonging, narrow | Parent's invitation, the note names the disciplines | Parent's drop |
| R8 | Tutor or relative | view lobe | Belonging, narrower | Same, naming chapters and a span | Span or drop |
| R9 | Supervisor, researcher | Kartora repo lobe | Writer, scoped to folders (REPO-16) | Kartora's invitation | Kartora's drop |
A model provider holds no relation. It's a web request from a skin lobe, and whatever it answers is the owner's own code speaking (ORG-7). The parent's AI reaches the family through the console's MCP, as the parent (WEB-9).
R4 and R5 are unlinked by address only. Kartora issues both, so it could connect them if it kept records of doing so. A blind way to issue R5 is possible later. For now, the promise is that Kartora doesn't know the child.
A family holds several children. It shares one subscription, one set of authors and one home, and each child has their own child and player lobes, map, shelf, knobs and invitation. The family's education country is the default for every child, and each child can have their own. The country is the lens: it sets the language of lessons and the mother tongue, foreign languages, typical ages and emphasis, while the graph stays the same. Every step of a session is a template with three parts, and the catalogue shows all of it in public. The mock-ups (kartora-mockups.html) raised these points, none of them decided yet.
| Finding | Why it matters | Proposal | Status |
|---|---|---|---|
| The parent's screen has no relation. | R1 and R2 are parent organisms owning the edge, but a parent on a phone at kartora.org is a browser. | Add R2b. Making that browser an owner through R2 is simplest, but a browser's security then holds the family. A narrower relation to the family lobe limits that, and it needs its own methods for what a parent does. | Open |
| Family setup is too hard. | A non-technical parent can't be asked for a local install and a Cloudflare account. The edge pilot is also unbuilt (HOST-7, HOST-26). | Set up the first families by hand, and offer a guided call. Solve it before real families, at step 7 of the Plan. | Open |
| Siblings on one device share one organism. | An organism is one site of a browser, so two children on a tablet at kartora.org are one browser organism. | One player lobe per child in that organism, and a second invitation adds a child to it. A "Who's here?" screen picks between them. It's no lock, so a sibling can open the other's map. A PIN is to be decided. | Proposed |
| The outbox is per family, colours are per child. | Kartora has to score each child apart, and shouldn't need to know they're siblings. | One R5 per child, each with its own code and a fresh ward. Kartora issues them all, so the limit noted under The relations still applies. | Proposed |
| Each country is a lens Kartora curates. | A country sets typical ages, emphasis, chapter names and check questions in its language. If a check question reads differently, colours stop meaning the same across countries. | Kartora keeps one lens per country and school language beside the graph, released with it, and its graph lobe answers through the child's lens. It's real work per country, so it paces which countries open. Who curates is still open. | Open |
| The age reference is lens data. | The atlas, the "typical for age" line and the reach chart all need a typical age per chapter, and it differs by country. | Each country's lens holds its own typical ages, never the chapters themselves. | Proposed |
| The lens is more than a language. | The same session for Germany and the UK differs in notation (0,4 and 0.4, 12 : 4 and 12 ÷ 4), units, money and order, and Germany's Länder differ in typical ages. | A lens holds language, notation, units, money, order and typical ages, by school system, language and, where it matters, region. | Proposed |
| The check can't be themed. | If each child's check reads differently, colours stop meaning the same. | The check's words are fixed and only translated by the lens. Only the line before it belongs to the story. | Proposed |
| A public catalogue changes what's paid for. | If anyone can read the graph, its content isn't the reason to subscribe. | The subscription pays for the service: the player and templates, prepared sessions, private checks and colours, releases. | Open |
| The child's part is the most personal data. | Interests, names and colours say a lot about a child. | They live in the child lobe and the outbox has no field for them. Kartora learns which template and version ran, never what world it was told in. | Proposed |
| Pictures for the child's world. | Stories want pictures of horses or a pitch, and generated images are hard to check. | A picture library drawn for Kartora, released with the templates. Generated pictures later, behind their own check. | Open |
family and sets the knobs.addChild raises a child lobe.player lobe to the same organism.author routes it to the chosen author.check.outbox sends fixed fields only.check scores them and answers.child updates the colours, and the parent sees them.Each is plain code in a faculty, so it's deterministic, replayable and provable by evidence (FAC-7). The first versions can be simple, because evidence is kept and a better version can recalculate. The method names are from memory and need the advisor's review.
| Algorithm | Question it answers | First version | Later |
|---|---|---|---|
| Colour | How well is this chapter understood? | Weighted recent results on check questions | Bayesian knowledge tracing, item response theory |
| Fading | What needs practice now? | A half-life per chapter that grows with each success | Half-life learned from data |
| Attribution | Which chapters does an answer count for? | Fixed weights on each check question, written by supervisors | Weights learned from results |
| Placement | Where is a new child on the map? | Walk the requires relations and bisect: skip what a strong result implies | Adaptive testing |
| Frontier | What can come next? | Opened chapters whose strong requirements are above a threshold | Ranked by blocked chapters, fading, the child's route |
| Root cause | Why is this child stuck? | Walk requires backward to the weakest ancestor | Known misconceptions on each chapter |
| Material mapping | What in the graph does this PDF touch? | The author picks from the chapter list, with confidence, and flags what maps to nothing | A mapping model of Kartora's |
| Template choice | Which templates for this chapter and child? | Shapes of the chapter's points against shapes each template carries, then the child's likes ("a story first") and variety | What engages this child, learned from finished and repeated sessions |
| Harness check | Is this session safe to show? | Each template's rules: claims come from the chapter's points, wrong answers are listed misconceptions, checks untouched, every branch ends, math recomputed, nothing from the avoid list | Second-model review, reading level |
| Outgoing filter | What may leave? | Allowlist of fields, age bands, coarse time, no text | Rotating IDs |
| Release move | What happens at a new graph release? | Each release ships a map of split, merged and renamed chapter IDs | Recalculate colours from evidence |
Checked against the spec and the code of 0.30.49. "First test" means it blocks a test with a few families. Each item still needs writing up as one statement for Nervur's authoring agent.
| Need | Where Nervur stands | Needed by |
|---|---|---|
| File from the screen. Upload a PDF or a photo in a session. | Not in the spec. The screen's inputs hold no file type (standard/tree/allow.ts), and LOOK-15 only carries files down to a page. It needs a rule under DIR-58. | Real families. For the first test, the parent's AI can read the PDF and send the request. |
| Edge pilot. Lay and update an edge from the local organism. | Edge cargo is built. The pilot's faculty and the organ's Node half are not (HOST-7, HOST-26, BUILD-9, CASE-6). | Real families. For the first test, an edge or small server can be laid by hand. |
| Long calls to a hosted model. A model call outlasts the longest timeout. | No change needed. A skin lobe answersFirst test, as Kartora's own work | |
| Taking new versions by a rule. A graph release lands without a parent acting. | LIB-8 says "or a rule an owner set". I didn't find such a rule in the library's README. To confirm. | Real families |
| Invitation after payment. A web event creates an invitation. | Proposal (CASE-17, WEB-3). A Kartora faculty can do it, so it likely needs no genome change. | Real families |
| Games as organs in a browser. A site adds its own organ to the home it embeds. | Proposal only (HOST-24). A browser takes its installer's organs alone (ORGAN-3). How organs reach a general app is also open. | Later. Templates are screen data drawn from the player's blocks. |
| Telling a closed browser or phone. "A new session is ready." | Proposals (HOST-20, HOST-24, HOST-25, LINE-4, LINE-5). The child pulls on opening, so this isn't blocking. | Later |
| The phone app. | Proposals (HOST-4, HOST-21). A browser covers the first stage. | Later |
| Remote MCP. A parent on the web or a phone reaches their organism. | nervur mcp runs on standard input and output, so it needs a desktop or server (WEB-9). Over the web it's a proposal (WEB-7, WEB-8). | Later. Desktop AI apps work for the first test. |
| Trust in the site's code. Whoever serves browser code holds its homes (HOST-5). | A public log of digests is a proposal (HOST-20). It would let families verify what Kartora serves. | Later |
Everything agreed, cut to what a few families need. Three or four of your own families, set up by Razvan by hand.
family, child, player, author, graph, and a thin model.Before any of that, the two-week paper test costs almost nothing and tests the method itself.
A first proposal, for the three of you to change.
| Area | Razvan (CTO, CPO) | Michael (CFO, funding) | Marcus (sales, PR) |
|---|---|---|---|
| Owns | Architecture, Nervur gaps, the data model, faculties, the graph format, the product | Company, money, legal, investors, pricing | Families, brand, story, partners, teachers |
| First 30 days |
|
|
|
| Depends on | Marcus for families and the advisor | Razvan for costs, Marcus for willingness to pay | Michael for legal wording, Razvan for what's true today |
Two risks. Razvan carries Nervur, the architecture, the product and the graph, which is the main bottleneck. And no one owns graph content yet. It's the core of the company, so it needs a named owner soon: the advisor, or a first hire.
| Decision | Who |
|---|---|
| Is the parent's browser an owner, or does it hold a narrower relation? | Razvan |
| Does a child on a shared device need a PIN? | Razvan |
| Results sent to the edge after each session, or kept in the browser and only backed up? | Razvan |
| The first templates, and who invents and tests new ones? | Razvan, with the advisor |
| What does the subscription pay for, now the catalogue is public? | Michael, with Marcus |
| Math alone first, or with the mother tongue? | Razvan, with the advisor |
| Is sharing metadata optional, or a condition of use? | All three, with the lawyer |
| Who pays, how much, and for what? | Michael, with Marcus |
| Who owns graph content? | All three |
| Where is the company registered? | Michael |