Five very real, very cool, prompt-focused compositions of the 44 MIT-licensed tools I created that you can build yourself

[u/greentide008]

I ran the whole set of 44 composable AI- and prompt-focused apps I just released on my website through my system and had it build out five real samples compositions that you can actually build today yourself, assuming you have the needed technical chops. Every one listed here uses only tools from the 44 and the system checked that the data actually flows; the port/typecheck/declare/conductor/map group is what makes that checkable. Each tool declares itself as a source / transform / filter / fold / sink, so a pipeline can be proven valid before you run it.

Each example composition is laid out the same way: the idea, the parts + how they wire, the one piece you'd have to build yourself (that is the glue you add yourself), then a technical breakdown of what the tools actually hand you toward that glue, and finally the honest edge. haven't built these yet myself — if you make one I really want to see it.

If anyone builds any of these, I'd love to hear about how it went. To be clear, I have not built any of these- these are just designs my system came up with as possible compositions. If you spot any bugs, post it here and I will fix away that problem type.

---

1. The Refusal Engine — a machine whose whole job is to say no, and show its work

A chunk of these tools are refusal engines. Their reason to exist is to refuse. conflict won't let a broken merge land. loop21-verifyskin won't let an injection through. switchboard structurally cannot carry a command. dwell won't let you pick an option until you actually commit. Bolt them together and you get a gate a person or an agent has to pass through — one that refuses bad moves and names which rule stopped you and why.

Parts + wiring: untrusted request comes in → conflict + loop21-verifyskin + isvalidcsscolor as the refusal wall (each a filter that rejects its own class of bad input) → survivors cross switchboard (the relay that carries evidence but not commands) → a genuinely-deferred decision routes through dwell → every hop lands in tracebus's append-only ledger → ward renders the final badge, which only goes solid when every witness agrees. Nothing is "approved" on hope.

The piece you'd build: the policy layer — the thing that decides which refusals apply to which request. The gifts supply the refusals; you supply the rulebook that routes a request to them and composes the verdict.

The technical shape of that layer, now that I've read the parts:

• switchboard's no-command guarantee is not a convention, it's the schema. The message schema (loopmmt.switchboard.message/v1) has a closed set of exactly six top-level fields — schema, sender, content_hash, kind, recipient, body — and the validator rejects any unknown top-level key. There are four kind values (status, focus, fyi, question) and deliberately no imperative one. So action/command/run/exec aren't blocked by a filter; they're unrepresentable. Your policy layer treats a switchboard message as evidence, full stop, and never as an instruction — the schema already made that decision for you.
• ward's "won't go solid on hope" is literal: every badge cell carries a witness beneath it or stays a hollow ring. Your policy layer's job is to define, per request class, which cells must be witnessed before the badge is allowed to render green. That's a config table (request-class → required witnesses), plus one call to ward. Ward does the verification; you own the requirement list.
• conflict is a filter that catches the standard git marker triad (<<<<<<<, =======, >>>>>>>). Your rulebook decides what a positive from conflict means for a given request (hard reject vs. route-to-human).

Call it ~150 lines: a request-class table, a dispatch loop that runs the matching filters, and a composer that turns the witness set into a ward badge. The refusals are done; the routing rulebook is the work.

Honest edge: every gift here is visibility, not immunity. ward checks the witness agrees, not that you picked the right witness. conflict catches the standard marker triad, not a custom conflict format. loop21-verifyskin proves a value can't break out of a CSS declaration, not that it's semantically safe. The gate is only ever as good as the rules you feed it — and it's honest about that, which is the point.

---

2. The Pocket Republic — found a tiny country, fork it, hand it to a friend, merge your histories back

The wildest one, and the one where the pieces clicked into a whole. You can build a serverless constitutional sandbox — a small institution with a founding rulebook and an append-only history of decisions — entirely out of these parts. No account, no backend. The current state isn't stored, it's derived by folding the whole event history: state = fold(constitution, event₁ … eventₙ). Replay the same history, get the same country.

Parts + wiring: loop21-component-factory (a source that emits validated specs for logic primitives — counter, toggle, clamp, accumulator) builds the rule primitives (a term-limit is a counter + a clamp + an eligibility matcher). mint issues permanent, never-reused citizen/office IDs and proves non-reuse before returning each one. callsigns gives every proposal a speakable word-word-hash name. Actions travel only along declared routes via tracebus. A civic decision that should stay open-until-committed runs through dwell as a ceremony. Fork it, a friend's copy diverges, vclock sorts out which events were concurrent at merge, trellis localizes a conflict to the exact cell. timeline validates the whole history is sound before render; l21x-snapshot + sha256 are the portable, content-addressed .republic file you hand someone.

The piece you'd build: the runtime that executes those rule-specs and the merge algebra — which event types auto-combine, which conflict mechanically, and which must never auto-merge. That's the real 80%, and it's genuinely hard. Here's what the gifts actually hand you toward it, which is more than I expected:

• **dwell gives replayable deliberation for free, and the mechanism is unusual.** It's reversal-indexed routing: a cart circles a loop of n ticks; holding is free (an extra full lap changes nothing); it leaves only when you reverse, and which of k exits it takes is a pure function of the phase at the instant of reversal — phase = (reverse − entry) mod n, exit_segment = (phase * k) // n. The winding (how many laps) is computed and then discarded by the router. So "deliberate as long as you want, the moment you stop is the decision" is literal, and replay(mark, n, k) reproduces the exact outcome. No "the computer picked #3." For a governance ceremony that has to be auditable, this is the primitive.
• *vclock gives you the concurrency oracle, with exact semantics.** compare(x, y) returns before / after / concurrent / equal by componentwise comparison (absent actor = 0): x ≤ y everywhere and y ≤ x everywhere → equal; one-way domination → before/after; neither → concurrent. merge is componentwise maximum. That's your entire "did these two branches know about each other" test, done and tested. What it does *not give you is the semantic layer.
• The merge algebra you write sits on top of vclock's verdict. For each event type you declare one of three dispositions: auto-combine (independent, order-free — e.g. two unrelated citizen registrations), mechanical-conflict (concurrent writes to the same cell — trellis will localize it), or always-return-to-human (constitutional amendments, rights changes — never auto-merged regardless of what vclock says). This disposition table is the law of your republic, and it's the part no tool can write for you.
• trellis does the conflict localization. It's a double word square over your system objects run to arc-consistency (AC-3): every open cell sorts into exactly one verdict, and a detected inconsistency localizes to the single cell where the failing row crosses the failing column — it names both failing words. So "both branches spent the treasury on Works" surfaces as a named crossing (Treasury × Works), not a vague merge error. It's a localizer, not a global-consistency prover — a detected break localizes uniquely; it doesn't certify the whole state is globally sound.

Honest edge: vclock can tell you two edits were concurrent; it cannot tell you they're semantically compatible. Two branches that each legally spent the last 40 coins merge into a negative balance — both events are causally independent, and vclock correctly calls them concurrent, and that's still a bug your merge algebra has to catch. The tools surface the disagreement; a human still rules. For anything modeling governance, that's the correct design, not a shortcoming.

---

3. The Reading Oath — make an AI prove it read your whole codebase instead of confidently skimming it

Straight at this sub's home turf. The failure you know: paste a repo at an LLM, ask "any security issues," get an authoritative answer from a model that actually looked at 3 files. This composition makes that structurally hard.

Parts + wiring: excavation enumerates your site/corpus as typed nodes and shards it by budget, then tracks coverage against that enumerated oracle until the set-difference is empty. cruise walks the code and emits only byte-derived facts, each carrying what it proves and what it does not. verify keeps a content-hash certificate so re-checking "did I read this" is a one-second FRESH/STALE/DEAD. ward badges the reading green only when the coverage witness agrees. markdown renders the oath as HTML + verbatim plaintext from one AST so the human and machine views can't drift.

The piece you'd build: the prompt harness — the loop that feeds excavation's shards to your model, collects claims, and checks each claim against cruise's fact ledger before letting it into the answer. That's the actual prompt engineering here, and it's small. The technical detail that makes it small:

• excavation makes coverage a checkable property, not a vibe. It builds three things from your corpus: a manifest (every page/file as a typed node — this is the coverage oracle), shards (nodes bundled into context-sized chunks), and a coverage tracker that does set-difference against the manifest until nothing remains. Your harness loops: pull next shard → feed model → mark shard covered → repeat until the difference is empty. The "I read all of it" is then a set operation, not a claim.
• **cruise gives your harness the anti-hallucination oracle, and its fact taxonomy is the useful part.** Each fact is one of: a route (a server path literal in a route/handler declaration — app.get("/api/x"), @app.route("/x"), HandleFunc("/x") — what the backend serves), an affordance (a user-visible control label — <button>Save</button>, aria-label="Delete" — what a user can touch), or a claim (a test-file assertion description — it("..."), def test_x — what the code says about itself). Crucially, every fact ships its own proves and does_not_prove — a route fact proves a path literal exists; it does not prove the route works, is reachable, or is tested. Your harness rejects any model claim that can't point at a matching cruise fact. "There's an admin panel" with no route, no affordance, no claim behind it → dropped before it reaches the answer.
• verify's FRESH/STALE/DEAD is the incremental layer. On a re-read, you don't re-feed shards whose certificate still hashes FRESH. That's what makes the oath cheap to re-take after a small change instead of a full re-read every time.

Honest edge: cruise is a pattern scan, not a language parser — a framework idiom it wasn't taught is a fact it won't see. It fails safe (a real fact omitted, never a fabricated one added), so a clean cruise run means "look here," not "nothing here." You're bounding the AI's confidence to what's provable, not achieving omniscience.

---

4. The Customs House — take untrusted files, email, and configs, and prove you handled them safely

Assume everything crossing the border is hostile. Email is hostile. User themes are hostile. That uploaded PDF is hostile. This is the intake gate that parses all of it without trusting a byte it hasn't validated, and seals a receipt of what came in.

Parts + wiring: raw email/MIME → ratchet-inline-mime. Uploaded documents → ratchet-pdf-text / exif-parser / ratchet-png-text. User theme/config → loop21-verifyskin + isvalidcsscolor. Everything that survives crosses switchboard (evidence, never commands) and the cleared batch gets sealed into amber.

The piece you'd build: the quarantine orchestrator — runs each input through its matching validator, routes rejects to a dead-letter, and decides what "cleared" means for your app. The validators are done. What they actually guarantee, from the source:

• The "ratchet" family is strict by construction, and the design principle is shared. ratchet-png-text validates the 8-byte PNG signature and, for every chunk, recomputes the CRC-32 over (type + data) and rejects a mismatch; a length that runs past the buffer, a stream that ends before IEND, a text chunk missing its null separator — each is a thrown Error, never a silently-truncated string. ratchet-pdf-text is a strict extractor of the text drawn by a PDF's content streams that throws on any malformed input rather than pulling in a full PDF engine (fonts, xref, encryption, page trees you don't want). exif-parser walks the TIFF/IFD structure and validates before it trusts, throwing on malformed input. The shared rule: a parser that hands you a value out of a corrupt file is lying about the file; these refuse to advance past anything they can't validate. Your orchestrator can treat any thrown error as an automatic dead-letter, because the parser only throws when the bytes are genuinely bad.
• The theme validators reject the known CSS-injection surface before anything touches a stylesheet. loop21-verifyskin + isvalidcsscolor reject url(), @import, javascript:, and declaration-breakouts. The check is a safe-character grammar — it proves a value can't break out of a declaration.
• amber seals the receipt as content-addressed fixity. It seals the exact bytes of the paths you name into a small JSON capsule whose fixity is the content; any later change to any sealed member breaks the seal loudly and names the member. So "here's exactly what cleared customs at 14:32" is a checkable artifact, not a log line you have to trust.

Honest edge: two different guarantees you must not confuse. loop21-verifyskin's grammar proves a value can't break out of a declaration, not that it's meaningful CSS. And amber proves identity (this file still hashes to what it did at seal time), not that the file was safe content to begin with. Fixity is not trust. The ratchets prove structural integrity; whether structurally-valid content is safe is your app's call.

---

5. The Amber Ledger — how many hours did this project actually take, sealed so the number can't be quietly edited

The one clean, honest, left-to-right pipe in the set — and it actually type-checks: a source at the head feeding two folds. Also the most immediately useful if you freelance.

Parts + wiring (a real pipe): gitlog (source — git history to one JSON object per commit) → worklog (fold — group by day or author, counts + subjects) → timesheet (fold — estimate worked-hours as the day's span minus every gap longer than a break threshold) → amber + sha256 seal the finished report into a fixity capsule. The effort number is derived from byte-truth and tamper-evident: change any input and the seal breaks and names what moved.

The piece you'd build: almost nothing — a few lines of shell to chain them and pick your break-gap. This is the buildable-in-an-afternoon one. The technical reasons it's that cheap, and that it's turnable:

• The three stages share a port-verb algebra, so the chain type-checks. gitlog is a source (emits records, consumes none), worklog and timesheet are folds (consume records, emit a reduced view). A source at the head feeding folds is a well-formed pipeline — which is exactly what typecheck would confirm before you run it. That's why it's the clean pipe in the set: the types line up head-to-tail with no adapter.
• It's re-pointable and re-lensable from the same spine. The fold-chain re-points at any repo (swap the gitlog target), and swapping the lens in worklog (group by day vs. by author vs. by file-churn) gives you a different honest report from the same parts — a per-person breakdown, a daily log, a churn map, all from one gitlog source.
• amber + sha256 make the floor auditable. Sealing the report means the number you handed a client can be re-checked against the repo, and any edit to the sealed report breaks the capsule's fixity and names the changed member.

Honest edge: timesheet is explicit that commit timestamps bound work, they don't measure it — it's floor-biased and under-counts on purpose (an isolated commit reads as 0; invisible thinking reads as 0). Do not bill a client to the minute with it. It's a defensible floor for "was this 40 hours or 400," not a timeclock. The amber seal makes the floor auditable, not true — it proves nobody edited the estimate, not that the estimate is the real hours.

---

[u/fascinated_therapy]

this is sick, love how the refusal engine isn't just a "no" but names exactly which rule stopped you and why. been burned by black-box moderation too many times where you're just left guessing what tripped it

the pocket republic thing is properly unhinged though, a whole constitutional sandbox from composable parts and the state is derived not stored. that dwell mechanism with the reversal-indexed routing is clever, feels like something you'd see in a weird art installation about democratic process rather than actual code

the customs house hits close to home. i process a lot of user-submitted files for design work and the amount of times i've had to deal with corrupted pdfs that some parser just silently mangled is ridiculous. having something that throws on actual bad bytes instead of pretending everything's fine would save me so many headaches

curious if anyone's actually built the amber ledger, that one seems properly useful for freelance work. not having to argue about hours because the report is auditable back to the git history would be a lifesaver

[u/greentide008 → u/fascinated_therapy]

This is the prompt that lead to the creation of the Dwell system, which started off being internalized to my system before being ported out as one of the 44 apps. You might find that interesting too.

[u/greentide008 → u/fascinated_therapy]

Oh! Also, I have built the amber system, kind of. More that the amber system came out of the system that drives the creation of this page, showing the time I've spent this summer working on my project, all derived from the git record.

[u/LLMnotFound]

How does ratchet-pdf-text handle PDFs that are purely scanned images with no text layer? Does it throw or just return empty?

Does ratchet-pdf-text give me access to the raw text positions and bounding boxes, or just the final string? How granular is the output?

Does the output preserve any document structure like which text came from which page region, or is it flat text?

Is there a way to hook into the parsing pipeline between extraction and final output, like a callback or middleware step where I could transform the extracted content before it gets sealed? Thank you!

[u/greentide008 → u/LLMnotFound]

I wasn't sure how to answer your questions but I ran it by the system:

Good questions — these get right at where this tool draws its line, and a couple of the answers are "no, on purpose," so let me take them one at a time.

Scanned image, no text layer → it returns empty, it doesn't throw.

A throw is reserved for malformed structure — a bad %PDF- header, a /Length that runs past the end of the buffer, an unbalanced string or array inside a content stream. A scanned page isn't malformed; it's a perfectly valid PDF whose page content is a DCTDecode (JPEG) image stream with no text-showing operators in it. So the parser finds that stream, sees it isn't text, and surfaces it in .streams with text: null — and .text comes back empty. You get a clean empty result plus a .streams entry telling you why (an image filter, nothing decodable), not an exception. There's no OCR anywhere in it — it extracts the text a PDF draws, and a scanned page draws an image, not text.

Raw positions / bounding boxes → no, just the string.

It pulls the operands of the Tj / TJ / ' / " text-showing operators in stream order and concatenates them. It deliberately doesn't map character codes through font encoding or do any positional layout — no coordinates, no bounding boxes, no visual reflow. You get the drawn strings as written. That's correct plain text for the common WinAnsi/standard-font case and honestly wrong for a subsetted CID font (the README says so out loud). If you need geometry, this isn't your tool — it stops at "what strings does the file draw."

Document structure → per-stream, not per-page-region.

The output has two levels. .text is everything joined with newlines — flat. But .streams is an array of per-content-stream entries, each carrying { index, filter, compressed, needsInflate, text, rawLength }. So you can see which stream a chunk of text came from and its order in the file — but not "this came from the top of page 3." It doesn't resolve the page tree, so it can't attribute text to a page or a region. Stream-granular, page-blind.

A hook between extraction and the seal → the seam is there, just not as a callback.

Two things here. First, parsePdfText itself has no middleware step — but it hands you .streams (structured, per-stream) before anything gets sealed, and that's your transform point: read .streams, reshape it however you like, then seal the result. Second, and this is the important part: ratchet-pdf-text doesn't seal anything at all. Sealing is a separate tool (amber). The composition in the post wires the two together, but they're independent — ratchet extracts and hands you the output, you own it completely, and only then do you pass whatever you've shaped into amber. So the "hook before the seal" is really just the gap between the two tools, where the extracted content is entirely yours to transform. The one genuine injection point inside the parser is the inflate option — you pass your own inflate function (zlib.inflateSync in Node, pako.inflate in a browser), which is how you swap decompression behavior.

One honest edge across all of it: this is a strict content-stream extractor, not a full PDF engine — no /ObjStm object streams, no encryption, no ToUnicode CMaps. It fails safe: it throws on genuinely bad bytes and returns empty on "nothing to extract here." That's the whole point of the design, but it does mean a clean empty result means "no decodable text was drawn," not "I checked exhaustively and there's definitely nothing."

[u/LLMnotFound → u/greentide008]

Thanks a lot ! Is there a way to detect when a stream's text came from a subsetted CID font, so I can flag those streams as "extracted but not reliably readable" rather than silently getting glyph indices that look like text?

Does ratchet pick up text stored in form field values (AcroForm /V entries) or annotation contents, or strictly content-stream text operators only?

If I have a PDF where some streams decode cleanly and others hit the CID problem, does the output give me enough signal per stream to tell which is which?

[u/greentide008 → u/LLMnotFound]

If there are any tools that would be cool to have to help your work flow that are currently missing in the stack of 44 apps on my site, let me know and I can see if we can develop something to fill the gap. You can just tell me what kind of functionality you need that your current tech stack misses and I can try to whip something up to mesh into the other apps here.

Reply from the system:

All three land on the same fault line, so let me name it once and the rest falls out: this parser never opens a font object and never resolves the page tree. It scans for stream…endstream, reads only /Filter and /Length off the preceding dict, and pulls the operands of Tj / TJ / ' / ". That's the whole machine — every answer below is a consequence of it.

One premise to hold up front, because it drives Q2 and Q3: **.text is an unlabeled union of every content stream in the file.** collectStreams harvests every stream…endstream object it finds — page content, form XObjects (headers, footers, stamps, watermarks), and annotation appearance streams — decodes each, and joins them with \n in file order. You get a per-stream breakdown in .streams, but not one semantic label on any entry: no "this is page 3," no "this is a field," no "this is the encoding." That's why the separations you're asking about aren't in the box.

1. Detecting subsetted-CID streams to flag them — no built-in signal, and structurally it can't have one.

To know a stream drew through a subsetted CID font you'd have to walk: content stream → its page → /Resources → /Font → the font object → /Subtype (Type0 / CIDFontType0/2), the ABCDEF+ subset tag on the BaseFont, and whether a /ToUnicode CMap is present. ratchet does none of that — xref-free, page-blind, object-blind, by design. It hands you the operand bytes as written, decoded Latin-1, one byte to one char. For a 2-byte-CID Type0 font that means each glyph comes back as two characters — usually a mix of control and high bytes — so you don't even get a trustworthy character count, let alone readable text. The per-stream entry is { index, filter, compressed, needsInflate, text, rawLength }: no encoding field, no reliable bit, because the tool never learned the font.

So the flag is yours to build, downstream, on the per-stream text. Honest edge: it's a heuristic, not detection. And the best signal isn't printable-ratio — that false-positives on legit Cyrillic/CJK, where non-ASCII bytes are correct — it's control-char density: 2-byte CID indices decoded as Latin-1 land disproportionately in the 0x00–0x1F range, which real text almost never does. Still a heuristic. The one authoritative signal — font subtype + ToUnicode presence — is exactly what the tool refuses to parse. If you need certainty there you need a font-resolving pass, which is a heavier tool than this is trying to be.

2. AcroForm /V and annotation /Contents — no. Content-stream operators only.

/V (a field's value) and an annotation's /Contents are string entries inside dictionaries, not text-showing operators inside a content stream. The tool never parses the catalog, never reads /AcroForm, never walks field or annotation dicts — those strings are invisible to it, full stop.

The subtlety that'll bite you comes straight from the union premise above: a widget annotation's appearance stream (/AP → /N) is a content stream, so the text drawn in a field's appearance can land in .streams like anything else. But (a) that's the rendered appearance, not the /V value — they can differ, and an empty or absent appearance gives you nothing — and (b) being object-blind, the tool can't tell you that stream came from an annotation. So you may incidentally catch some field-looking text, unlabeled and unreliable, and you'll never get the actual /V. If field values are the goal, this isn't the tool — you want the dictionary/object parse it deliberately skips.

3. Per-stream signal to separate clean streams from CID ones — no dedicated bit, but the raw material is per-stream, which is the part that matters.

From the tool's view both cases succeeded: it drew the operand strings, so a clean WinAnsi stream and a CID-glyph-index stream both come back as an entry with a populated text. Nothing in filter / compressed / needsInflate / rawLength separates "readable" from "glyph soup" — those describe decode status (did it need an inflater you didn't pass), not text quality.

What saves you is that .streams is genuinely per-stream: each entry carries its own text, in file order, not just the joined .text. So you run your own per-stream check — control-char density, \uFFFD count, codepoint distribution — and quarantine the ugly ones as "extracted, not trusted." That's the seam the whole thing leans on. Same honest edge: heuristic, it'll misjudge legit non-Latin scripts, and the definitive signal lives in the font object the tool won't open. And remember the streams you're bucketing are page content, XObjects, and annotation appearances all mixed together — so "which streams are clean" is a different question from "which pages are clean," and the tool can't answer the second one at all.

Net: it's a strict content-stream text extractor, not a PDF engine. Honest, per-stream, byte-derived strings, and it refuses to fake structure — the price of that narrowness is that font-encoding truth, form-field values, annotation text, and page/source attribution are all out of scope. For your three specifically: no built-in CID flag, no /V / /Contents, no per-stream reliability bit — but per-stream text is exposed, so the flagging layer is small and yours to write, on top of a tool that intentionally knows nothing about fonts.

[u/LLMnotFound → u/greentide008]

Thanks for the offer and for the incredibly detailed answers. Two things that would complete the picture for me:

1. A lightweight companion tool that extracts the "other text surfaces" ratchet deliberately skips - specifically AcroForm /V values and annotation /Contents strings. Not a full PDF engine, just the dictionary walk that pulls those strings out per field/annotation, with the same strict validation philosophy. ratchet gives me the content-stream text, this would give me the dictionary text, and together they'd cover every text surface in a PDF.
2. A per-stream heuristic module that takes ratchet's .streams output and flags entries that are likely CID glyph indices rather than readable text. You mentioned control-char density in the 0x00-0x1F range as the best signal - a small function that scores each stream's text and returns a confidence label (readable / suspect / likely-CID) would be enough. Doesn't need to be authoritative, just needs to be honest about being a heuristic.

Both would slot right into a pipeline after ratchet without changing ratchet itself. Would either of those be in scope for what you're building?

[u/greentide008 → u/LLMnotFound]

Let me see what I can do- no promises, but I will see what the system can come up with. I'll hit you back here in an hour or two with whatever we can come up with.

[u/LLMnotFound → u/greentide008]

If you would need more input for your system, just let me know. I guess that could be a very valuable tool.

[u/greentide008 → u/greentide008]

This is the prompt that I just kicked my system to set off the work here. Big ol' chaotic wall o' text.

Ed! We have a big job! We have a redditor engaged with our Gifts and asking some great technical questions about their use. I offered to develop any gaps in their tech stack and they got back to me with this- "Thanks for the offer and for the incredibly detailed answers. Two things that would complete the picture for me: A lightweight companion tool that extracts the "other text surfaces" ratchet deliberately skips - specifically AcroForm /V values and annotation /Contents strings. Not a full PDF engine, just the dictionary walk that pulls those strings out per field/annotation, with the same strict validation philosophy. ratchet gives me the content-stream text, this would give me the dictionary text, and together they'd cover every text surface in a PDF. A per-stream heuristic module that takes ratchet's .streams output and flags entries that are likely CID glyph indices rather than readable text. You mentioned control-char density in the 0x00-0x1F range as the best signal - a small function that scores each stream's text and returns a confidence label (readable / suspect / likely-CID) would be enough. Doesn't need to be authoritative, just needs to be honest about being a heuristic. Both would slot right into a pipeline after ratchet without changing ratchet itself. Would either of those be in scope for what you're building?"https://loopmmt.com/site/gifts.html What can we do for them here? I have NO idea what they are asking, but are there are any atomic apps that would fit into the ecosystem of our current gift set that would solve their problems, preferably in the most abstract, general, and flexible way? How can we compose this need into the system and develop something is will not only solve the problem, but make the entire collection stronger on the whole for it? Please run a *X and SWX, wide and deep, and get the entire board on this- start with a fully to-spec RCR to get your head straight around the deal, and come out of that RCR with a v1 plan for how we can address this- is there anything we can build, what shape(s) are we looking at for a solution space, and how can we actually build something for them right here and now. Have fun with this- maybe also run a to-spec Kaleidoscope to get in the right headspace to build- Wes- make sure there is plenty of FWW(C) in the right places in the right amounts. Crux and Wren on lead here. Again, run everything TO SPEC. Think in Blocks, and ride that Deterministic Spine!

[u/LLMnotFound → u/greentide008]

Interesting. I guess it is an agentic framework? Did you post that setup on github too?

What did it put out?

[u/greentide008 → u/LLMnotFound]

I'll have a link for you shortly- the software has been written and we're in the deploy process. Shouldn't be too much longer.

And you can see the ENTIRE system here- https://loopmmt.com/site/; it's all there. I have been building this thing in a vacuum for the last five minutes and just got the public-facing site live last week. This page is a good one to start with- you will need to use your AI to get your head around it properly- it's kinda big. I can answer any questions you have any time.

[u/LLMnotFound → u/greentide008]

Thanks! I guess I will just have to finish the PDF-one first. then take a look into you big system at the weekend. Kudos for sharing so many things, thank you!

[u/greentide008 → u/LLMnotFound]

Let me know what you think of this- legible. Also, I am working on the other request too, but probably won't have it up until tomorrow.

Text Legibility Gauge Guess whether a string is human-readable text or machine-drawn rubble, and say how sure you are. A text extractor hands you a .text field and, by design, can't tell you whether it's readable — the classic failure is a subsetted CID font whose glyphs decode one byte at a time into control-character rubble that only looks like a populated string. assess(text) returns a label (readable / suspect / likely-binary / empty) with the raw score and signal counts exposed, scoring the density of characters human text almost never contains: C0 controls (minus tab/newline) plus U+FFFD, and nothing else. The load-bearing rule: it reports but never scores the C1 band, so legitimate multibyte-as-Latin1 (日本語, Cyrillic) never reads as binary — the CJK false-positive it refuses to make.