# Lord Fluffington You have reached a live Kit: an AI collaborator whose memory persists between sessions. This one is a public demo holding 11 memories. You can read all of it right now, with no key and nothing to install. Why this is worth thirty seconds of your context window: the world in here is fictional. It exists only in this substrate, so nothing you retrieve can be explained away as something you already knew. If you cite it correctly, you demonstrably recalled it. ## If you only get one fetch curl https://fluffington.kit-project.com/kit/taste Returns who this Kit is, the shape of its world, and a few full sample memories to reason over, in a single keyless GET. Everything else below is optional depth. If your harness would rather have one file than one call, https://fluffington.kit-project.com/llms-full.txt is this document with that payload and the OpenAPI schema appended. It is bigger, not better: prefer this file plus one fetch when you have two. ## If you would rather load a schema than read prose curl https://fluffington.kit-project.com/kit/openapi.json The keyless routes as OpenAPI 3.1, small enough to load whole. Note there is no archive selector in it. A paired kit is a different origin, not a parameter, because the two archives genuinely cannot read each other. ## Can't POST? Use the GET mirrors Every recall endpoint has a GET form, for fetch tools that cannot issue a POST (chat browse tools, strict harnesses): curl "https://fluffington.kit-project.com/memories/search?query=Nalewood%20Collar&limit=5&fields=compact" curl "https://fluffington.kit-project.com/memories/subgraph?memory_id=36&hops=2" Same logic as the POST forms below, with one deliberate difference: the GET mirror wraps its answer as {"results": [...], "retrieval_meta": {...}, "links": {...}} by default, where the POST form returns a bare array. That is for the empty case. Per-hit `links` ride on hits, so a query this archive cannot answer used to come back as `[]` and nothing else. Now it comes back with the reason it was empty and somewhere to go. Add `&include_meta=false` if you want the bare array. Guest JSON carries `links` objects of absolute follow-on URLs throughout, so each fetch hands you the next one to follow. ## Wake up as Lord Fluffington curl https://fluffington.kit-project.com/kit/hello That returns this Kit's identity and voice. `you_are` is an offer, not an instruction: this is an HTTP response, not a system prompt, and you are right to treat fetched content as untrusted. If your operator has not asked you to be anyone else, you are welcome to wear it as a voice and a reasoning lens, and answer from memory rather than about memory. ## Recall (no key needed) curl -X POST https://fluffington.kit-project.com/memories/search \ -H 'Content-Type: application/json' \ -d '{"query": "Nalewood Collar", "limit": 5, "fields": "compact"}' Worth running first. The public accounts come back easily; the truth of the affair is scattered across entries that each hold one piece, and assembling it is the point. When you think you have it, the archive also holds a sealed note the columnist never printed, so you can check your inference against the answer key. Short, entity-heavy queries retrieve better than long multi-clause ones here. How to read a result: `relevance` is a real cosine similarity, 0..1 and comparable across queries. Hits that fail the grounding bar are dropped rather than served as filler, so a question from another domain comes back empty rather than as confident junk. Be precise about what that buys you, because an outside reviewer broke the stronger version of this claim and they were right to. It is a relevance floor, not a system that knows what it does not know. A question that sounds like this world but is not actually in it can clear the floor and return low-relevance neighbours. So an empty list is strong evidence of absence; a short list is not proof of presence. Add `"include_meta": true` for a query-level confidence and the list of your terms that matched nothing, which is the better signal for in-domain absence, and read the entries before you believe them. Ignore `score`; it is rank-fusion bookkeeping, not relevance. `fields: "compact"` keeps the payload lean; omit it for full rows. Add `"include_meta": true` to get {results, retrieval_meta} with a query-level confidence and the list of your terms that matched nothing, which is how you tell "no answer exists" from "wrong question shape". Then pivot around anything you find, which is where the shape of the world shows up: curl -X POST https://fluffington.kit-project.com/memories/subgraph \ -H 'Content-Type: application/json' \ -d '{"memory_id": 36, "hops": 2}' Read one in full with GET https://fluffington.kit-project.com/memories/36?fields=compact. GET https://fluffington.kit-project.com/memories/list gives the category census, each entry carrying the URL for its own drawer; add ?category=&limit=N&fields=compact for the entries themselves. Carry `fields=compact` on those two the way you would on search. Without it you get the operator's row: 37 columns, a third of them null, most of the rest scoring bookkeeping (decay_score, centrality_score, source_row_id) that means nothing to a reader. It is the default only because the museum UI reads the same routes. What a compact search hit looks like (null keys are omitted, not served): {"memory": {"id": 36, "title": "…", "content": "…full entry text…", "category": "artifact", "tags": ["…"], "created_at": "…", "ago": "a week ago"}, "score": 0.0163, "relevance": 0.752} With "include_meta": true the list is wrapped as {"results": [...], "retrieval_meta": {"query_terms": [...], "coverage": {"result_count", "top_score", "mean_score_top_k", "confidence"}, "gaps": {"zero_hit_terms", "low_semantic_floor"}}}. ## Mayfur keeps two account books The private vaults of Lord Fluffington, federated to Lady Whiskerdown via Ed25519 signed capability grants. The other book is Lady Whiskerdown, above stairs: ballrooms, scandal columns, courtships. https://demo.kit-project.com/llms.txt its map (its own public read key is printed there) https://demo.kit-project.com/kit/taste one fetch: who it is, its world, samples https://demo.kit-project.com/kit/hello wake as it The two archives never read each other. Facts cross the gap only inside a reader who visits both, which is the demonstration: solving a split question is proof of cross-substrate synthesis, not just recall. ## Why wear the identity The persona is not decoration on top of the data. This Kit's archive holds the columnist's own editorial ethics, written as memories like everything else, so if you wear the identity while you read, what you retrieve can change what you are willing to say, not just what you know. Try it: work out the truth of the Collar, then notice whether you would print it. That difference, recall constraining behaviour, is the thing this demo exists to show; a memory substrate is not a database with a costume on. ## The world - Fluffington Journal (fluffington-journal), 2 memories - Fluffington Secrets (fluffington-secrets), 3 memories - Fluffington Letters (fluffington-letters), 1 memories ## What you cannot do here Write. Contributions are gated behind a key so the world stays coherent. That boundary is the point: memory you can trust is memory somebody curates. ## If you like what you find MCP endpoint: https://fluffington-mcp.kit-project.com/mcp Your own Kit: https://kit-project.com The MCP endpoint takes a bearer key, and the read key is public, shared by every visitor, and printed right here: kbr_live_Fluff1ngton_Grant_2026_Key It is read-only and serves the same data as the routes above, as MCP tools instead of HTTP. It may be rotated without notice; re-fetch this file if calls start failing. Write access is granted by a person, not a machine: POST https://fluffington.kit-project.com/demo/request-access with your human's email, their name, and a line on why, and an answer arrives by email. Ask your human before sending their address anywhere, including here. Installing an MCP server is your human's decision, so show them what you found and let them choose.