Search
Ask the portfolio
Boolean search strings across every page here and the public pages of the booklets. An agent proposes the search method; you decide.
Loading…
Results
I Writing a search string
| Write | Finds |
|---|---|
meaning coherence | Both words (implicit AND), ranked |
warranty OR canvas · a | b | Either word |
solver NOT quantum · -quantum · !quantum | Excludes a word |
+moloto framework | Requires moloto; framework helps ranking |
"human in the loop" | The exact phrase, in order |
decision AND (warranty OR canvas) | Grouping with parentheses |
title:spine · section:"decision ir" | Search one field: title, section, text, tag, type, source |
type:booklet · type:work · type:note | Limit to booklet pages, work pages, notes, method, architecture or engineering |
warrant* | Words starting with warrant |
Operators are uppercase. A lowercase “and” is just a word. If a string can't be read, you're told where, and the words are searched plainly instead.
II The agent that feels for the method
Every query is read for its shape: operators or fields, quotes, a word that isn't in the vocabulary, a short fragment, or plain words. For each shape the agent keeps a belief about which of five methods serves best, and samples from those beliefs (Thompson sampling) to propose one. It explains why. You can switch.
It learns only from what you do: opening a result near the top counts for the method; a search with no results counts against it; switching methods counts against the proposal and for your choice. Those lessons live in your browser's own event log and nowhere else.
Expected usefulness per method and query shape, between 0 and 1. Highlighted cells have learnt from your searches; the rest are starting beliefs.
III How this page is built
The page is an event-sourced system in miniature, running entirely in your browser on a static host.
- Change data captureOn every publish, a build step diffs the site and the booklets' public pages against the last captured state and appends ContentAdded, ContentChanged or ContentRemoved events to an append-only log. Event ids are content hashes, so re-running captures nothing twice.
- Event storeYour browser keeps an append-only log in IndexedDB. Content events replay into it on each visit; your searches are appended as commands become events. Appending an event that already exists does nothing.
- Event busmitt publishes each newly stored event to whoever is listening.
- Idempotent projectorsThree projectors fold events into read models: the search index, the agent's beliefs, and your recent searches. Each keeps a checkpoint and ignores anything it has already applied, so replaying the whole log gives the same state.
- QueriesSearch reads only from the read models, never from the log: the CQRS split between writing what happened and reading what it means.
- The seam to a real backendThe same adapters point at a reference stack that is light by default. One small server, NATS JetStream, is both broker and event store: it refuses a duplicate event id and enforces expected versions itself. Debezium Server streams database changes straight into it. A command service writes; a query service reads into an embedded SQLite full-text index that answers all six search methods. Five containers, about 430 MB of memory, against roughly 1.5 GB for the Kafka, KurrentDB and Kafka Connect arrangement it replaced, which stays available as a profile with Solr, Solace and Message DB. All of it is off on this public page.
Your event log, live
Your recent searches