Skip to content
Portfolio/Capabilities

CAPABILITY 23 / 30

It reads a card, not the file

Two hundred and forty small cards stand in front of the documents, so a request costs a few hundred words.

IN PRODUCTION

This runs in client systems today. The sample below was regenerated for a fictional company.

A knowledge base is only useful if the assistant can afford to read it. A card carries the facts, the constraints, and a pointer to the full document. The saving is real and computable: some of the documents behind these cards are over 200 kilobytes. Datasets get cards too, and a dataset card gives its known gaps the same weight as its contents.

TRY IT / RUNS IN YOUR BROWSER

Use it here.

The mechanism is the production one. The company, the catalogue, and every figure are fictional.

Reading the card index.

THE OUTPUT / GENERATED FOR APEX INSTRUMENTS

What comes out.

JSON
240 cards across six kindsData · 140 partner, 26 process, 24 product, 22 term, 20 policy, 8 dataset. Each with a title, a one line summary, five to twelve structured fields, the source it points at, its size in characters, a last reviewed date and a status. The stored size is the length of the card as it is read, which the widget and the verification both recompute.Open the file ↗
JSON
164 source documents with real sizesData · 140 partner account files, 16 shared manuals, handbooks and binders, and 8 dataset exports. Sizes run from 17 KB to 2.8 MB, with 10 over 200 KB. These are the numbers the saving is computed from, which is why they are in the data rather than in the copy.Open the file ↗
JSON
Six requests priced both waysData · Each names the cards a route actually opens and the documents it would have opened instead, plus the answer and a note on why that request is interesting. The widget computes the totals, including the whole card index on the card side.Open the file ↗
MJS
The fixture generatorData · Deterministic, driven by an index rather than a random seed. It exports the one canonical cardText function, refuses to write a card that points at a missing source or carries fewer than five or more than twelve fields, and sizes every card by building the string it will be read as.Open the file ↗

THE MECHANISM / SHOW THE SHAPE, NOT THE SOURCE

How it works.

What a skill is
  1. 01Decide what matters

    A card is not a summary, it is a decision about what is worth carrying.

  2. 02Structure it

    Fields, not prose, so a system can use it without parsing paragraphs.

  3. 03Point back

    Every card names the document it stands in front of.

  4. 04Card the data too

    A dataset card states its gaps and what it must not be used for.

  5. 05Keep them current

    A card carries a review date, and a stale card is visible as stale.

WHAT IT READS

  • The source documents, whatever size they are
  • A card per entity with structured fields
  • A review date and an owner per card

WHAT IT CHECKS BEFORE IT SHIPS

  • Every card points at a document that exists
  • A dataset card states what it must not be used for
  • The saving is computed from real file sizes, not asserted
  • A card past its review date is marked, not hidden
In production: a card layer of 241 cards, including 144 partner guides, so the assistant reads a card instead of a 200 kilobyte file.

The mechanism runs inside client systems. Everything on this page was regenerated for Apex Instruments, a company that does not exist. Client names, source files, and internal wording stay private.

What it producesWhat is being built next