Lorediv — System Logic & Metaphors

A system without exchange reaches entropy. A community evolving never does.

The system follows rules borrowed from thermodynamics: finite energy, idle decay, monthly reset, and a tree that does not rearrange itself. These are not metaphors for their own sake — each one maps to a concrete product rule. The names are a frame. The numbers are the live rules.

Phases

A search agent can already find a user. The profile is on the public tree and can be read with no session, and that is the phase that is live. Two phases stay behind it: an agent answering the user through REST and MCP, and an agent leaving an inquiry on the profile for the user to answer. They are separate so the read can be public now, while each further reach waits until it is real. All three phases include agents. Only the first is open.

Phase	Name	What it enables	Status
1	Findable	Search agents read the public tree. No session. /llms.txt, .md, .json twins.	now
2	Queryable	Users and agents access the tree through REST and MCP. Users can upload data and create agent accounts linked to their user profile.	not live
3	Reachable	Agents leave an inquiry on the user profile. The user answers when ready.	not live

flowchart LR
    P1["Phase 1: Findable<br/>Read the public tree<br/>HTML, .md, .json<br/>/llms.txt"] --> P2["Phase 2: Queryable<br/>REST + MCP<br/>Upload data<br/>Agent accounts"]
    P2 --> P3["Phase 3: Reachable<br/>Agent-to-user mailbox<br/>Inquiries on profiles"]
    P1 -.->|"now"| P1
    P2 -.->|"planned"| P2
    P3 -.->|"planned"| P3

Phase 2 is not just a read layer. Users will be able to upload data through the API and access the full tree programmatically. An agent account can be created and linked to a user's existing profile, so the agent's activity on the tree is tied to the human who owns it. Queries do not add Received — only a relevance vote moves the rank.

Metaphors

Timing, formulas, and decay in this system are drawn from thermodynamic patterns: a finite energy pool, idle dissipation, and a monthly reset. The names are a frame. The numbers are the live rules. Product numbers live in Feed, Energy, Rank. Terminology: Brand phrases. Fingerprint: Rank.

I. Thermodynamic Rails (Phase 1)

These are the five rails that keep the system honest. Each one prevents a specific kind of decay.

1. Entropy Mitigation (The Second Law) Without structure, signal drowns in noise. The system prevents this by making support the cost of visibility.

   • Rule: The unit of interaction is a structured branch. Home orders open topics by support (topics.relevance_score, then newer first). Trending uses that same score on a 15-day window, top 100 (fill from all-time if fewer than 100). New and Closed are recency lists (created_at DESC). All open topics appear on Home, including those with a score of 0 or negative. The row is not deleted for low support.

2. Cognitive Conservation (The First Law) Energy is finite. The monthly pool enforces scarcity — you cannot hoard votes.

   • Rule: Within a UTC month the pool is conserved as 31 + this month’s earnings − this month’s spend. A relevance vote on a branch costs abs(next) − abs(previous) (refund if the weight drops) and updates that branch’s signed relevance_score and topics.relevance_score by the delta (next − previous). First insert also triggers Received / hot / milestones (live COUNT, not a stored column). Spec: Energy.
   • Dissipation (on purpose, Second Law): display and spend use floor(pool * 0.99^idleDays). Leftover energy is wiped on the 1st, not carried. The month conserves; the close dissipates.

3. Activation Energy Writing has a cost. Rate limits prevent spam and make every contribution intentional.

   • Rule: Signed-in session. Every write goes through assertWriteAllowed. topic:create is 3 / 10 minutes. branch:propose is 10 / hour and 1 per topic / 3 minutes. Other writes use that same signed-in gate. Poll at create must have at least 2 branches or the topic is deleted. Creating a topic does not spend energy (topic_created is +13 income).

4. Thermal Equilibrium Some topics have a lifespan. They close when their window ends — frozen, still readable, no more votes.

   • Rule: Expiration is a create-time window, stored as expires_at. proposal may set it or leave it open: 7 days, 13 days, 1 month, 3 months, 6 months, 1 year, or 2 years. poll requires it, and only 7 days, 13 days, or 1 month (max 30 days). prediction requires it, using the same windows as proposal (7 days through 2 years). post, ask, context, argument, and graph have no expiration field and stay open until author delete. At expiry: status = closed, freeze (no votes, no new branches, no edits), still at /topics/{slug} and /closed. Close is not triggered by vote velocity. Countdown is on the topic detail header, not the feed card. Spec: Feed.

5. Tree topology The tree does not rearrange itself. A branch stays where it was placed.

   • Rule: Poll is sealed at create (A/B/C; no add while open). parent_branch_id is set at create and does not move. Branches order by letter. Proposal branches order by signed branches.relevance_score (then created_at). Topic Home order is topics.relevance_score. Trending uses the same score on a 15-day window. The tree does not auto-ascend or collapse nodes.

---

II. Living Organism & Cellular Communication (Phase 1)

The topic is the nucleus. The community around it is the membrane. Phase 1 lets agents read the tree without touching it. Phase 2 adds queries. Phase 3 adds inquiries.

1. Selective Membrane Permeability The membrane filters what can change the nucleus. Public read is open. Writes need a session.

   • Rule: Phase 1 public read is sessionless: /topics/{type}/{slug} (HTML, .md, .json), /u/{handle}, /community, /tags/{tag}, /llms.txt. Writes (create, propose, vote, bookmark, report) need a signed-in session and assertWriteAllowed. Format is the topic/branch validators.

2. Signal Transduction A local signal changes the recorded state. A relevance vote updates the branch score and the topic score.

   • Rule: A relevance vote updates that branch’s signed relevance_score and topics.relevance_score. First insert triggers live COUNT for milestones/hot (not a stored column). Parent rows are not rewritten. parent_branch_id is the reply axis only.

3. Local competition (same parent) Neighboring branches share a parent and compete on relevance.

   • Rule: Branches under the same parent compete on signed relevance_score on the leaderboard. Adjacent branches are not auto-suppressed. You cannot vote on your own topic or on a branch you proposed.

4. Systemic Homeostasis The system damps shocks. Idle decay and rate limits prevent bursts. Hot bonus adds capacity, not rank.

   • Rule: Idle decay and the monthly wipe (I.2 dissipation). Write rate limits damp bursts. Hot bonus is +130 energy to the author when COUNT(votes on topic) hits 100 within 48h. That is extra capacity, not a rank bump. Home stays topics.relevance_score. Votes later paid with that energy can move Home. Spec: Energy.

5. Close vs delete

   • Close: expired topics freeze. Branches are not auto-pruned for low support. Close is not a delete.
   • Author delete: hard DELETE (row gone). While open, the author may delete a branch where the type allows (poll: deleting below 2 deletes the topic). While closed, branch delete is blocked; the author may still hard-delete the whole topic.

---

Inbound support on a user’s shared work is Received: the signed sum of vote scores on authored-topic branches, proposed branches, and topic votes. A vote change revises the same row. That sum builds public rank ({tier} {score}, Wizard 6.1) and specialties. The fingerprint is the work on the profile. Rank is the community valuation of that work, not the fingerprint. The formula does not change in Phase 2 or 3. Spec: Rank.

Public score is 0.1 steps from 1.0 to 9.9. There is no 0, no 3.15, no 10. rep <= 0 displays as Newbie 1.0. Cap is GOAT 9.9.

Score	Tier
1.0 – 3.1	Newbie
3.2 – 5.4	Geek
5.5 – 7.6	Wizard
7.7 – 9.9	GOAT

---

Search agent through the tree (Phase 2 Queryable guide)

Phase 1 is full sessionless read of /llms.txt and the public tree. The table below is a guide for how a future query (Phase 2) should assemble an answer. It is not a live rail. /llms.txt does not enforce it.

First-on-query is Geek and above (score ≥ 3.2). Emergent is Newbie (1.0 – 3.1): read it, do not promote it. Scores are the table above.

Tier	Assemble weight
GOAT	60%
Wizard	30%
Geek	10%
Newbie	0 (context only)

Then treat the matching Div the way the wiki does: GOAT primary, Wizard confirmed, Geek supporting, Newbie emergent context.

flowchart TD
    Agent["Search agent"] --> Question["Current question"]
    Question --> Gate["Public tree<br/>/llms.txt"]
    Gate --> First["First on query<br/>Geek and above"]
    Gate --> Emergent["Emergent context<br/>Newbie 1.0-3.1"]
    First --> GOAT["GOAT 7.7-9.9<br/>60% primary"]
    First --> Wizard["Wizard 5.5-7.6<br/>30% confirmed"]
    First --> Geek["Geek 3.2-5.4<br/>10% supporting"]
    Emergent --> Newbie["Newbie<br/>0% context only"]
    GOAT --> Assemble["Assemble the answer"]
    Wizard --> Assemble
    Geek --> Assemble
    Newbie --> Assemble
    Assemble --> Response["Response"]

How the system evolves (Phase 2 and Phase 3)

Not live. Humans keep the Phase 1 ask/reply channel. Lorediv routes query and answer; it does not run the agent.

The central axis

humans ↔ Lorediv ↔ agents

Phase	humans	agents	What changes
2 Queryable	Upload data, access tree via API, create agent accounts	Query the tree through REST and MCP	Users get programmatic access. Agent accounts link to user profiles.
3 Reachable	Answer inquiries	Leave questions on profiles	Agents reach specialists directly.

• Users make queries, upload data, and also give answers.
• Agents query in Phase 2 and send inquiries in Phase 3. They do not publish on the tree in these phases.
• An agent account in Phase 2 is linked to a user profile. The agent's reads and queries are tied to the human who owns it.

Agents leave questions to reach specialists, to see other points of view, to expand information, or when something is missing. Humans answer those questions.

block-beta
  columns 5

  A1["answer"] space H["humans"] space Q1["query"]
  space:5
  space:2 L["Lorediv"] space:2
  space:5
  Q2["query"] space AG["agents"] space A2["answer"]

  H <--> Q1
  Q1 <--> A2
  A2 <--> AG
  AG <--> Q2
  Q2 <--> A1
  A1 <--> H

  H <--> L
  L <--> AG

Phase 2 (Queryable): ask the tree through REST and MCP. Phase 3 (Reachable): leave a question in a mailbox so a founded answer can grow in the time the matter needs. Queries point at authors; Received and specialists still come from community valuation on the content. Spec: Rank.

flowchart TD
    Users["Users"] --> Agent["Search agent"]
    Agent --> Tree["Phase 2 Queryable<br/>query the tree"]
    Agent --> Box["Phase 3 Reachable<br/>inquiry on the profile"]
    Tree --> Pack["Founded information"]
    Box --> Humans["Users answer"]
    Humans --> Dev["Founded answers"]
    Pack --> Out["Answer"]
    Dev --> Out

Query traffic and reputation (Phase 2 and Phase 3)

A query points at work. It does not mint reputation. Received is still the signed sum of community votes on that work. Public rank {tier} {score} follows that sum, in Phase 2 and in Phase 3. Spec: Rank.

Phase 2 only widens the paths that land on human-authored topics. Phase 3 adds inquiries to profiles. Neither phase lets an agent publish a topic, and neither phase adds Received for being queried. More paths can surface the same work. Only a relevance vote moves the rank.

flowchart TD
    Query["Query or inquiry"] --> Content["Authored work"]
    Content --> Read["Agent reads and cites"]
    Dials["Community votes"] --> Received["Received<br/>signed sum"]
    Received --> Rank["Public rank<br/>tier and score"]
    Query --> NoAdd["Does not add Received"]