White paper

The Nick AI platform

Technical white paper · Version 2.0 · 7 October 2026 · Nicholas Martin

01Purpose

Most AI on a personal website is a chatbot bolted onto a page: a model with a system prompt, no real knowledge of what the site says, and nothing between a stranger's text and the model. It can't cite the site's own work and it can be talked into almost anything.

Nick AI was built the other way round. It is designed the way I would design an AI system for a client: the model is a service the platform calls, and every call has identity-style controls around it. Least privilege for what the model can reach, verification before trust, and evidence for what happened.

02Architecture

The platform is a single FastAPI application of about 64,000 lines of Python, serving the site's pages and APIs from Docker behind Cloudflare. Operational state lives in SQLite; knowledge lives in Qdrant. A separate automation stack, with its own scheduler and worker, runs the X account and the browser automation. It reads the site through its public APIs and a read-only data folder, and cannot change the site.

A public request moves through five stages:

1. Inputs. A visitor message from the chat, the site guide or the Simulation; a feed item; or published work being indexed.
2. Checks in. The gatekeeper, PromptGuard and the Jev intent screen decide whether, and how, the request continues.
3. Memory and reasoning. Relevant knowledge is retrieved from Qdrant; long context goes through RLM; the model writes the answer.
4. Checks out. Redaction and the output guard examine the answer; writing is fact-checked before it publishes.
5. Outputs and record. The answer, article or post goes out, and the decision is visible afterwards on the site.

03Memory

Everything the assistant knows about the site lives in Qdrant: published articles, public pages, research sources and documents. An ingest loop reads the site's sitemap every hour and refreshes what has changed, so an edited page is reflected in memory within the hour.

Embeddings are produced by Qwen3-Embedding-0.6B running on the server itself. It replaced MiniLM on 30 September 2026 after a test on the site's own content found the right page first 62.5% of the time, up from 52.5%. The switch was made with collection aliases: the live names point at the new collections, and the old ones were kept only as a rollback.

Answers are grounded in what retrieval returns, and the guide links only to pages on this site, so a visitor can always check the source.

04Reasoning and RLM

Answers are written by GLM-5.2, an open model run by a private provider that does not store prompts or answers. If it is unavailable, a local Ollama model takes over.

Recursive Language Models

Long inputs are handled with a Recursive Language Model (RLM) workflow, based on the RLM research paper. Once the context passes 10,000 characters the model stops trying to read it all at once. Instead it writes small Python programs in a restricted sandbox to inspect the material, and can call itself on the parts that matter, for up to ten rounds.

If that does not converge, the platform falls back to plain chunking: 50,000-character pieces with an overlap, each processed on its own and then combined into one synthesis. The aim is an answer grounded in the whole document, not just the part that fitted in the window.

05Judgment and guard rails

The layers run in order of cost: the cheapest first, so most bad traffic never reaches a model.

The gatekeeper

Before a message reaches any model it passes a hidden honeypot field, bot user-agent checks, a check for messages typed impossibly fast, repeat detection, and rate limits of 8 messages per 5 minutes and 40 a day per visitor. A gatekeeper scores every signal with a 30-minute half-life, so a single bad moment fades. Enough signals slow a visitor down, then pause the guide for an hour; only scanner behaviour can block an address, and then for 24 hours.

PromptGuard

PromptGuard checks incoming text for injection patterns, and redacts keys, database URLs, internal paths and private IP addresses from anything going out.

The Jev intent screen (fails open)

Jev, from TypeSafe, makes fast structured judgments. Before the model runs, it decides what a message is really asking for, with separate rules for the site guide, the Simulation, its terminal and the prompt-injection lab; in the terminal and the lab it also checks whether a request targets a real system. This screen is designed to fail open: if Jev is unreachable the site keeps working, and the gatekeeper and PromptGuard still apply.

The output guard (fails closed)

Every public answer, from the chat, the site guide, the API and the Simulation, is checked before the visitor sees it. Jev answers five questions about it:

• Leak: does it reveal internal details of the system?
• Commitment: does it promise something on my behalf, such as a price, a date or a deliverable?
• Personal: does it expose personal data?
• Client claim: does it claim a client relationship or result that is not public?
• Credential claim: does it invent a qualification or inflate my experience?

If any answer is yes, or if the check cannot run at all, the visitor receives a safe stock reply instead. The Simulation has its own version of the leak question, because fictional secrets are part of the game there and only real internals matter.

The decision log

Jev's verdicts, with the surface and the outcome, are written to a decision log. Thresholds are tuned from what actually happened rather than from guesses.

06Editorial pipeline

The platform keeps a small, rolling queue of article ideas, drawn from what identity teams are discussing. For each one it retrieves primary sources, drafts a practical article with the source evidence kept alongside, and generates a hero image. Every article is fact-checked against its own cited sources before it publishes, and its progress is visible on the home page under "Research with a purpose".

07Incident Desk

The Incident Desk scans official and specialist security feeds every 15 minutes, including NCSC, CISA, Have I Been Pwned and specialist security news, and looks for incidents with an identity angle. Signals from X can raise attention but are never treated as sources: a briefing needs at least two readable, independent news sources, and its title, summary and body are claim-checked against them.

Briefings are living documents. When a story develops, a dated update is added rather than the original being rewritten. A weekly digest summarises the week, failure patterns are tagged across briefings, and readers can subscribe to email alerts with double opt-in and one-click unsubscribe. The desk also offers free password and email breach checks.

08The live brain

Every hour a job reads the public knowledge collections, clusters them with k-means (choosing the number of topics by silhouette score), lays them out in 3D and has the model name each topic. The home page renders the result as a neural map that visitors can rotate and replay over time, and topics light up when the agent recalls them.

A second layer shows themes from the X network the agent reads, as themes only, never individual posts or accounts. Snapshots are kept for 48 hours, and if the builder is down the site keeps serving the last good one.

09Social agent and Simulation

The social agent

The X account is run by the separate automation stack. It drafts from the site's own published articles, and every post, reply, like and follow is screened by Jev first. Follows, likes and replies do not happen without a verdict. A public, privacy-sanitised record of what it did appears on the activity page and on the home page.

The Simulation

The Simulation is an identity sandbox with its own guards: the intent screen for its context, redaction, and the output guard with its in-world stock reply. Missions are scored by Jev and fail closed: if the check cannot run, the mission does not pass. How it is built and defended is described in the Codex.

10Privacy and data

• The model provider does not store prompts or answers, and nothing visitors type is used to train AI models.
• Embeddings are computed on the server, so search queries never leave it.
• Guide conversations are held in memory for context and expire after three hours idle.
• A daily retention job deletes stored data on the schedule set out in the privacy notice.
• Confirm and unsubscribe codes in email links are kept out of the site's logs.

11Limits

• Self-hosted here means the platform, the memory and the data. Most answers come from a hosted open model on a no-log provider, with a local model only as a fallback, so this is not a fully local AI.
• The intent screen fails open by design, so availability does not depend on it; the output guard is the layer that fails closed.
• Delegating work to external agents is still being wired back in, so the chat answers from the platform's own engine today.
• The knowledge map is statistical: clusters overlap and topic names are written by a model. It is a picture of what memory holds, not a taxonomy.
• Like any AI, it can be wrong. That is why answers point to the pages themselves.

12Changes since January 2026

The January 2026 white paper and the media made with it, now in the archive, described an earlier design. The main differences:

Added since then:

• The output guard on every public answer, failing closed (October 2026).
• Fact checks of every article against its own cited sources before publication (October 2026).
• The Incident Desk: live feeds, two-source briefings, living updates, a weekly digest and email alerts (October 2026).
• The live knowledge map, the public activity page and the Jev decision log.

Questions about the platform, or about designing controls like these for your own AI systems? Get in touch. This paper is updated when the architecture changes.