Libranis documentation · concept

Primitives

One record type, first-class relationships, scopes, bounded sessions, dated tethers, and the three facets every record carries.

Canonical identifier
https://libranis.com/docs/primitives/
Last updated

Definition

The Libranis primitives are the small set of structures every part of the system is built from. There are five, plus three facets that every record carries.

PrimitiveOne line
LibranThe one record type. Everything the system holds is one.
RelationshipThe connection between two entities, held as a record in its own right.
ScopeThe region of the graph a conversation or an action is bound to.
SessionA bounded unit of one relationship's conversation.
TetherThe dated grant of what a party may do with an entity.

Purpose

To keep one model under every surface. Because there is one record type and one relationship type, a new experience does not require a new schema, a new permission system, or a copy of anyone's data.

What it is not

  • Not an ontology a caller must accept. These are engineering structures with observable behavior. No philosophical claim is required to use them.
  • Not terms shown to users. The application says "chat", "your people", "who can see this". The words below are architecture, and appear in this documentation because an external system reasoning about Libranis needs them.
  • Not a type hierarchy. A libran's kind is a discriminator on one record type, not a subclass in an inheritance tree.

Libran

Definition. The one record type. A person, an AI participant, a physical thing, a place, an organization, a document, a photograph, a conversation, a meeting, a unit of work, a plan, a relationship — each is a libran. A libran has a canonical identifier, a kind, three facets, and a steward.

Identifier. A libran's canonical public address is https://libranis.com/<id>, where <id> is a 16-character lowercase Crockford base-32 string. The address asserts no kind on purpose: a memorial, a business, a house, and a transaction are all addressable, and none of them is an "object". Modalities hang off the same address rather than off separate namespaces.

Stewardship. Every libran is stewarded by some party, which decides what it discloses. A libran is its own primary steward where no other party holds that role.

Why one type. Because the alternative is a schema per application, and a schema per application is what makes a house in one product unable to be the same house in another.


Relationship

Definition. The connection between two entities, held as a first-class record rather than as a field on either side. A relationship carries its own permission boundary, its own conversation, and its own dates.

Consequences that follow from making this a record:

  • The conversation belongs to the relationship. A chat is not a message list attached to a user; it is the relationship expressing itself. This is why a conversation about a water heater persists as the water heater's conversation, independent of which person opened it.
  • Permissions live on the relationship. "Who can see this" is a property of the connection, not of a role name held by a user.
  • The graph of relationships is the privacy architecture. A meeting is a group relationship with its own boundary; the private side-conversations nested inside it have their own boundaries and are not visible to the meeting. Multi-party privacy needs no new primitive.
  • Relationships are not restricted to people. The same primitive holds person↔person, person↔AI, person↔thing, person↔organization, and organization↔thing. A house, a vehicle, a device, a service location, and a transaction relate through it unchanged.

Dates. A relationship's dates belong to what the relationship is doing, not to the relationship itself, and they are episodic rather than a single window: a party may hold a relationship, end it, and hold it again years later. A relationship therefore carries a sequence of first/last pairs, of which only the most recent is operative. A relationship may also carry several concurrent expressions — being entitled to something free and something paid at the same time is normal, not a conflict.


Scope

Definition. The region of the graph a conversation or an action is bound to. Scope determines what may be considered when answering, and what an action may reach.

How it is resolved. From the entity in view. The scope of what a person is looking at is the nearest scope-bearing ancestor of it — a paragraph inherits its document's scope; a document may be promoted to its own scope explicitly.

Two axes not to confuse. Containment is one libran holding another — a book holds chapters, a place holds things — and grants nothing. Scope is the relationship a conversation lives inside. A thing being inside a place does not put it inside that place's conversation.

Crossing scopes. Several scopes may be open at once, and moving between them is a view operation that never disturbs work in progress. Reading across scopes is opt-in and auditable: it requires an explicit grant, which is cheap within a person's own scopes and refused across tenants except through an explicit grant.


Session

Definition. A bounded unit of one relationship's conversation. Sessions exist so that a conversation can continue indefinitely without a model ever being asked to hold an unbounded history.

Three states. Open — a conversation that can be returned to; several may be open at once, one per scope. Live — the one open conversation currently being worked in; exactly one at a time. Closed — bounded and sealed with a compact summary.

Sessions chain; scopes nest. Within a scope, the thread is a chain of bounded sessions linked by successions rather than one growing session. Returning to a scope resumes its open session, or starts a fresh one seeded from the last one's summary, or starts a new one if neither exists.

The seam is not shown. The person sees one continuous conversation about that part of their world. The boundaries between sessions are plumbing.

Re-entry never replays. A returning session resumes from the sealed summary, not from the whole transcript. The transcript remains available as a record; it is not injected into a model's window.


Tether

Definition. The dated grant of what a party may do with an entity. Authority is a tether, not a role string and not a flag on a user.

Distinct from three neighbours it is often confused with:

It is notWhich is
IdentityWho you are. One per person, permanent, free.
A credentialHow you prove you are that identity. One or many, revocable, some lent by a third party who can take them back.
An entitlementWhat you have purchased. Zero or many, and never required in order to exist or to claim something.

Tethers weaken; they do not vanish. Access degrades through tiers of contact rather than being switched off: full mutual legibility, then a one-way tier where a party keeps what it already had but receives nothing new, then a residual tier that exists but grants nothing. This is why a past relationship can be reasoned about without a system pretending it never happened.

Tier of contact is not tier of service. A person on the free path is in full contact and receives less. A lapsed subscriber may be at a reduced tier having previously received more. The two axes are independent.


The three facets

Every libran carries three facets. They are defined here operationally; no metaphysical claim is required, and the one-line form is enough to place almost any fact.

Boundary is what it is. Expression is what it is doing. Coherence is what holds it.

Boundary

Identity · ownership · authorization · consent · visibility · scope · allowed actions · disallowed actions · transfer rules.

Boundary answers what is this, whose is it, and what may cross its edge. The permission model lives here. Boundary viewed as a region is the scope a conversation lives in; the same boundary viewed as a gate is the governance of what crosses it. These are one thing seen two ways, not two mechanisms.

Expression

Human interface · API · MCP tools and resources · messages · calls · meetings · work items · object representations · current state.

Expression answers what is it doing now, and how does it show up. Expression is the facet of change: if a fact about a thing changes while the thing remains itself, that fact is Expression. A subscription being active, a session being open, a work item being in progress — all Expression. This is the rule most often got wrong, and getting it wrong is how state ends up in the wrong place.

Coherence

Canonical identity · relationship graph · provenance · state consistency · versioning · history · context inheritance · cross-surface continuity.

Coherence answers what binds this to other things, and what keeps it the same thing across surfaces. Retained history is evidence of coherence rather than coherence itself. Supersession and revocation live here, because they are statements about whether a binding still holds.

Placing a fact

The question "which facet could hold this?" always answers yes, at every level, because each facet is itself structured the same way. That question is malformed. The usable form:

Do not ask which facet could hold the fact. Ask what the fact is about. Identify the subject first; the facet follows.

The factIts subjectWhere it goes
"The subscription is halted"The relationshipThe relationship's Expression
"The participant list is sealed"The boundaryThe Boundary's own Coherence
"This name renders as Shirley Septic"The expressionThe Expression's own Expression
"This held from March to September"The expressionThe Boundary of the Expression

Facet or entity

A string on a record is the wrong shape when the thing it names should be a record of its own. The decisive test is whether one event changes many holders at once — a shared cause across many records is a relationship, not a property. Four supporting signs: the value changes while its holder does not; its cause is external to the holder; the old value still exists and is still referenced; it carries distinct dates for when it held, when it became known, and when it was recorded.

Most strings are correctly strings. Type discriminators, enumerations, provenance markers, paths, and external identifiers stay as they are.

These primitives do not define their own rules. Authority, consent, and disclosure are the same across every Libranis surface and are specified on Security and consent.

Examples

A relationship as a record. A homeowner and a plumbing company both relate to one water heater. There is one water heater. The homeowner's relationship and the company's relationship are separate records with separate permissions and separate conversations. The company's technician sees service history; the homeowner sees everything they have kept; a visitor sees whatever the homeowner published, which may be nothing.

A session chain. A person has been discussing their house with Ari for a year. Underneath, that is many bounded sessions, each sealed with a summary and succeeded by the next. On screen it is one conversation about the house.

Expression as the facet of change. A vehicle's odometer reading is Expression — it changes while the vehicle remains itself. Its VIN is Boundary. The fact that this record and the title record refer to the same vehicle is Coherence.

What is live today

All five primitives are in production and carry the running system. The three facets are how records are actually stored, not a description layered over something else. Terminology in this section is stable; it is the substrate the rest of these pages describe.

Machine interfaces

PurposeAddress
Concept explanations for modelshttps://libranis.com/llms.txt
MCP serverhttps://mcp.libranis.com/mcp
MCP resource explaining the libran primitivehttps://mcp.libranis.com/resources/how-to/primitives
Public read-only HTTP APIhttps://libranis.com/api/v1
OpenAPI descriptionhttps://libranis.com/openapi.json

Libranis · Ari · Orbitals · ScanThis · Security and consent

All Libranis documentation