SemText

a semantic text format

One HTML file,
in place of Markdown.

SemText is a semantic text format: a single HTML file that a language model reads and writes the way it writes Markdown today. The difference is what the text can say. A fact, a step, a caveat, an incorrect statement, a term and its definition are each written as what they are — a tag and a few attributes — so the structure is in the text itself, not inferred from it.

Read it as-is. A model, a diff, a terminal, or an editor shows readable text in document order, with every qualifier spelled out next to the thing it qualifies. Nothing has to run first.

Open it in a browser and the same markup becomes working web components: flashcards flip, quizzes score, tabs switch, code copies, terms preview, and a reader bar tracks the outline. All of it works from a double-clicked file in any current browser, and none of it changes the text the model wrote.

auth-notes.html · what the model reads
<sem-note variant="warning">
  Refresh tokens rotate per use —
  each exchange retires the last one.
</sem-note>

<sem-facts view-as="flashcards">
  <sem-fact id="f-jwt" kind="concept">
    <statement>JWTs rotate per session</statement>
    <conclusion>Short-lived access tokens;
    the refresh grant issues a new pair.</conclusion>
    <incorrect-statement>Store the token in
    localStorage for durability.</incorrect-statement>
  </sem-fact>
</sem-facts>

The idea, in one control

Switch the view. The content does not change.

These four facts are authored once, as <sem-fact> elements holding a <statement>, a <conclusion> and a <incorrect-statement>. view-as on the <sem-facts> element selects how they render — switching it rewrites nothing, and the records a machine reads are the same in every view. One file, three readers:

  • semtext.html — the in-browser render: double-click the file and it runs.
  • semtext tui — the same file in an interactive terminal for people: navigate sections, flip flashcards, run quizzes.
  • semtext --render — plain text for agents: collapsed sections expand on demand, embeds load, and the file arrives as its own summary.
sem-shell · demo/example-deck.sem.html · code view
$ cat demo/messages/code.txtcode view — the pager over the deck file:     bat demo/example-deck.sem.html Up/Down line · PgUp/PgDn page · / find · n/N next/prev · q quit (placeholder — this shell types and runs the script once the shell bundle lands)
demo/example-deck.sem.html
sem-shell · demo/auth-notes.sem.html · terminal
$ cat demo/messages/tui.txttui view — the interactive terminal over the notes file:     semtext tui demo/auth-notes.sem.html arrow keys or click: sections, flashcards, quiz · Esc exits (placeholder — this shell types and runs the script once the shell bundle lands)
sem-shell · plain-text readers
$ cat demo/messages/cli.txtcli view — plain text out, one command per reader:     render-card demos/render-demo.card    semtext --render demo/auth-notes.sem.html    render-card demos/render-subsection.card    render-card demos/render-toc.card (placeholder — this shell types and runs the script once the shell bundle lands)

The browser pane renders demo/example-deck.sem.html itself — the same file double-clicking opens. The shell panes type their first commands once the shell bundle lands. More sample documents sit in the showcase menu below.

Reading

Long-form documents, with the reading affordances left in.

The recall elements above are one use of the vocabulary. Most documents are read, not drilled, so it also carries what a long document needs: a glossary whose terms preview on hover, references with backlinks, a dated chronology, listings with provenance, notes that can float in the margin, content addressed to a named audience, and links that reach into closed disclosures. The examples below are the real content; the live affordances — hover previews, sorting, the reader bar — run on the showcase.

Glossary

A sem-properties block with view-as="glossary". Each property carries an id; a term in prose is a plain anchor to it. With scripts off, the link simply jumps to the definition; the reading bundle adds a preview on hover or focus.

record
One entry in the array extraction returns: a type, an id, qualifiers, a payload of fields, and one line of text.
tier
Which script, if any, is driving the document: none (CSS only), or the one SemText bundle.
tier marker
The data-sem-upgraded attribute the runtime sets on what it wired; every hide rule is gated on it.

Chronology

sem-chronology is CSS only: a list of sem-event items in chronological order, each with a when and an optional status. Extraction gives each event a positional ordinal.

  1. Jan 2026 · done

    Format spec v0 and the Tier-0 schemas.

  2. Mar 2026 · done

    Fallback tier, extraction contract, scripts-stripped artifact.

  3. Sep 2026 · current

    Reading experience: foundations, then the prose elements on this page.

  4. 2026 Q4

    Theme pipeline and the reader chrome.

Audience

A sem-audiences block declares the profiles a document knows; any element may carry audience. Nothing is removed — content for a profile is hidden until a reader claims it, and extraction never consults visibility, so a filtered document still extracts whole.

Code

sem-code carries what a listing cannot: a filename, a language and a set of marked lines. The listing is written directly inside the element — it becomes a <pre><code> when the reading bundle runs — stays byte-identical, and extraction reports it verbatim.

doc.html
<p>Rotate per use<a href="#r-rfc">[1]</a>.</p>
<sem-references id="refs" kind="bibliography" role="list">
  <sem-reference id="r-rfc" role="listitem"
       href="https://www.rfc-editor.org/rfc/rfc6749" cite="RFC 6749">The OAuth 2.0 Authorization Framework, §10.4.</sem-reference>
</sem-references>

Reader

sem-reader is the bar pinned to the top of the showcase page: one per document, a direct child of the root wrapper, mints nothing. Its outline is generated from the headings, h2 on down. Focus, type size, face and colour scheme are attributes on <html> that the vocabulary CSS keys on, remembered in localStorage when the browser allows it.

Source, Markdown, tables

sem-source lets a reader flip a section between the rendered result and the markup that produced it. sem-md holds Markdown as its text and renders it in the browser — tables above all. sem-table wraps an authored <table> and adds sort and filter; there is no JSON payload — the markup is the data. All three run live on the showcase.

References

sem-references numbers its entries with a CSS counter in every tier. Citations in prose are plain anchors; the reading bundle adds a preview on each, a backlink per citation, and an external link where an entry has an href.

  1. The central invariant: extraction output is identical whether or not JS ran, under any view, and after any interaction. extraction.md §5
  2. In print, a reference's URL appears after its text — inside the references block only, never at the citation. sem-references.md

Quick start

What you actually write.

A SemText document is an HTML file. The vocabulary is custom elements with plain attributes — <sem-facts view-as="flashcards">, <sem-step status="done"> — so any editor, template language or generator that emits HTML can write one, and the browser parses it with or without a script.

doc.html · minimal SemText document
<!doctype html>
<html lang="en" data-sem-theme="minimal-tech-light">
<head>
<meta charset="utf-8" />
<title>Auth notes</title>
<link rel="stylesheet" href="https://cdn.semtext.dev/v0/semtext.css" />
<link rel="stylesheet" href="https://cdn.semtext.dev/v0/semtext-theme-minimal-tech-light.css" />
<script defer src="https://cdn.semtext.dev/v0/semtext.js"></script>
</head>
<body>
<sem-enhanced-document>
<h1 data-kind="title">Auth notes</h1>
<sem-note variant="warning">
Refresh tokens rotate per use — each exchange retires the last one.
</sem-note>
<sem-facts view-as="flashcards">
<sem-fact id="f-jwt" kind="concept">
<statement>JWTs rotate per session</statement>
<conclusion>Short-lived access tokens; the refresh grant issues a new pair.</conclusion>
<incorrect-statement>Store the token in localStorage for durability.</incorrect-statement>
</sem-fact>
</sem-facts>
</sem-enhanced-document>
</body>
</html>

Save it, double-click it. That is the whole workflow. Written the older way — <div class="sem-note" data-variant="warning"> — it renders and extracts the same; that spelling is the compatibility alias, documented once in the spec's Appendix A. The cdn.semtext.dev links are the planned origin; today the same files ship in the spec repo.

Adding it to a project

  1. 01Copy semtext.css — and, if you want a theme, semtext-theme-<name>.css — next to your document, and set data-sem-theme on <html> to that theme's name.
  2. 02Add semtext.js. Link it, or paste it inline for a document you intend to send as a single file.
  3. 03Write the content with sem-* elements where interactivity or machine-readability pays. Ordinary HTML stays ordinary HTML.

Want your own look? The theme file format is documented in the theme conventions section of the spec .

Surface

Everything that ships.

One script and one stylesheet, plus an optional theme file. Everything a document needs rides in the single semtext.js — the components, the reading chrome and the Markdown renderer — so there is no build step and nothing else to link.

semtext.js
One bundle: Lit 3 components, reading chrome and the Markdown renderer · global SemText
semtext.css
Structure for the sem-* classes. Reads --sem-* tokens, declares none.
semtext-theme-<name>.css
Optional. Token values only, plus a dark-mode block. A new theme is a copy with new values.

The vocabulary

Twenty-one element types mint records: sem-agent, sem-note, sem-facts and sem-fact, sem-details and sem-detail, sem-procedure and sem-step, sem-properties and sem-property, sem-views and sem-view, sem-reveal, sem-progress, sem-chronology and sem-event, sem-code, sem-references and sem-reference, sem-table and sem-md. sem-reader is chrome and mints nothing.

Browse all of them — purpose, options, and the authored markup — in the tag reference.

A sem-agent block is document-level metadata aimed at a model, carried by the same file a person is reading. It is inert to a browser and it is a record to an extractor.

Scope

What it is not.

SemText ends at the document: no build step, no service, no install. The limits below are the design, not the gaps.

SemText is a markup vocabulary, two stylesheets and one script. It is not a CMS, a site generator or an application framework, and it has no opinion about how you produce the HTML. A new version should not break markup authored against an older one. New elements and attributes land alongside the ones a document already uses — never swapped out from under it — so a file authored today keeps rendering as the vocabulary grows. Pin a version when you ship. Nothing in the SemText bundle is React, and none is planned. Lit 3 is the only runtime dependency, and it is optional — the fallback tier has none.

The obvious questions

Markdown has nowhere to put the attributes that make a datum machine-readable — no way to mark a conclusion as distinct from a distractor, or a step as blocked. A converter that compiles Markdown into SemText is worth building; the canonical artifact stays HTML, because that is what the browser, the terminal and the model all read. A model can read any HTML. What it cannot do reliably is tell a conclusion from a distractor, or a caveat from a heading, when nothing in the markup says so. The claim here is narrow: the attributes remove that guesswork, and the extraction contract makes the result stable enough to cite. Noizu Labs, Inc. and The Robot Lives use SemText internally — agent-facing docs and demo documents are authored in it. SemText is a published spec with a reference implementation; there are no third-party deployments to point at and no benchmarks to quote.
Open the showcase

Showcase

  • CLAUDE.md — repo guidance one file serves to an agent and to a human
  • Documentation — long-form docs with callouts, listings and citations
  • Onboarding — a checklist that tracks itself — steps, progress, facts
  • Agent — an agent record and the facts it answers from
  • Command — a command spec: arguments, steps, invariants
  • Skill — a skill file with tabbed reference and examples
  • Data viewer — sort and filter a table authored in the document
  • Embedding — reuse one document's sections inside another
  • sem-shell — the interactive terminal element over a virtual file system

Integrations

  • The Robot Learns — live app; courses as SemText with per-user quiz tracking is the planned add-on planned
  • The Robot Plans — live app; issue submission into Jira, ClickUp or GitHub is the planned add-on planned
  • The Robot Knows — live app; the knowledge-base hookup is the planned add-on planned
  • Draftamo — live app; mockups and UML renders from hosted projects or local XML is the planned add-on planned
Browse the reference

Integrations

Documents that do more than read.

The reading and extraction core is free and static. Integrations connect a document to live systems — tickets and knowledge-base answers cited inline, quizzes and courses readers work through, mockups and UML rendered in place. Each is wired to its real logic as it is built, and none change how a document reads.

  • Ticket embedding

    An account key enables ticket embedding — live tickets from your tracker, cited inline like any other datum.

    embed.semtext.dev/tickets?account=key_live_7f3k9x

    TRK-241 · open

    Streak reset wipes a completed quiz score

    assigned @dana · tagged semtext · cited inline from your tracker

  • The Robot Knows hookup

    Point a document at your knowledge base, so facts and procedures draw on live KB entries.

    KB-118 · account keys · v3

    What does an account key unlock?

    Embedding — tickets, quizzes and course progress render inside your documents; the reading core stays open.

    source: The Robot Knows · entry cited on the fact

  • The Robot Learns courses

    Courses load as SemText and track each reader's quiz progress; sign-in is prompted when tracking starts.

    course · Working with SemText

    1. 1 · documents & records — done
    2. 2 · reading views — current
    3. 3 · extraction — up next

    progress tracked per reader · sign-in prompted on start

  • Private & public quizzes

    Private exams and quizzes from The Robot Learns embed in your pages, beside a public catalogue of embedded quizzes.

    quiz · public catalogue

    Which attribute selects an alternate rendering?

    • a · key
    • b · view-as — correct
    • c · role

    scores in place · private exams use the same embed

  • Draftamo mockups & UML

    Mockups and UML renders from Draftamo-hosted projects, or from local Draftamo XML.

    sem-doc reader records

    checkout-flow.uml · rendered by Draftamo

  • The Robot Plans issue submission

    Submit an issue from the page itself — The Robot Plans files it in Jira, ClickUp, or GitHub.

    SEM-312 · Integration carousel keyboard focus ring

    integrations enhancement

    Reported from this page — reporter, page section and build attached automatically.

    filed via embedded form → The Robot Plans (GitHub)

1 / 6 — Ticket embedding

Extend

Extend the vocabulary.

Org-specific components, and a submission tool where you talk an element into existence: the agent drafts the vocabulary entry, builds the Lit component, and wires the submission flow.

The vocabulary is open at the edges: an organisation can define its own elements for what its documents say over and over — a runbook step type, a compliance datum, a product fact. The submission flow below is planned, not shipped — nothing here clicks yet. Custom elements are Lit components with a vocabulary entry, and the AI submission tool assembles both. Describe the element to the submission agent — a name, what it means, one example. The agent drafts the vocabulary entry and builds the Lit component. Review the render, then submit — the component ships in your org's bundle with its submission flow attached.