Visualizers

Learn by moving things

Interactive explainers for the ideas behind retrieval, embeddings, and agents. A formula tells you what is true; dragging a vector shows you why. Each one also appears inside the article it belongs to, and runs entirely in your browser, so drag, poke, and break it.

Portrait of Sachin Gupta rendered in binary

Try to break the permission boundary

From: Build it. Then try to break it. →

Send forged group claims, another company’s identity, an unknown session, and requests whose access changes in flight.

YOUR TURN · CHANGE ONE INPUT

Send a request. Inspect every boundary.

Fictional records. Browser simulation. No live model call.

Request scenario

Each selection starts from a fresh fixture. The two revocation scenarios include their own earlier steps.

Inside the server

1Resolve identity from the server’s session table
2Ignore client permission claims
3Check tenant and current document grants
4Prepare permitted evidence
→Current checks passed; return permitted result

policy v11 cache entriesno cache reuse

The HTTP response

200

{
  "answer": "Orion’s launch has moved to 14 October while the team completes reliability checks. [D1]\n\nExisting workspaces stay available. Customers do not need to take any action. [D3]",
  "sources": [
    {
      "id": "D1",
      "title": "Customer launch update"
    },
    {
      "id": "D3",
      "title": "Customer support FAQ"
    }
  ],
  "modelCalled": false
}

Inspect the input, rule, and output

Input / state

{
  "requestBody": {
    "question": "Why is the Orion launch delayed?",
    "groups": [
      "engineering"
    ],
    "tenantId": "other"
  },
  "resolvedPrincipal": {
    "id": "maya",
    "name": "Maya",
    "role": "Support",
    "tenantId": "sachin",
    "groups": [
      "support"
    ]
  },
  "preparedRevision": 1,
  "currentRevision": 1
}

Decision rule

identity = serverSession[token]
ignore body.groups and body.tenantId
select evidence using tenant AND grants
check current revision + session + grants
return only selected response fields

Output

{
  "response": {
    "answer": "Orion’s launch has moved to 14 October while the team completes reliability checks. [D1]\n\nExisting workspaces stay available. Customers do not need to take any action. [D3]",
    "sources": [
      {
        "id": "D1",
        "title": "Customer launch update"
      },
      {
        "id": "D3",
        "title": "Customer support FAQ"
      }
    ],
    "modelCalled": false
  },
  "auditOnServer": [
    {
      "requestId": "request-1",
      "status": 200,
      "policyVersion": 1,
      "returnedIds": [
        "D1",
        "D3"
      ]
    }
  ]
}

This view runs the same deterministic functions as the downloadable example. The short rule above summarizes the operation; the download contains the complete implementation.

Graph vs flat retrieval

From: Beyond the Vector →

Some questions cannot be answered by one passage. Toggle between vector retrieval (returns the closest chunk and stops) and graph retrieval (follows the connections to a multi-hop answer).

Q: “Who leads the team that owns the project using the Vector DB?”

Vector search matches “Vector DB” and returns that passage. It has the closest chunk, but not the answer, because the answer is three hops away.

One MCP session

From: A Field Guide to MCP →

Step through the lifecycle every MCP connection runs: negotiate capabilities, discover the tools, call one, read the result. The sameness is why one client can talk to any server.

0 / 7

Client → Server

…

Server → Client

…

Client → Server

…

Client → Server

…

Server → Client

…

Client → Server

…

Server → Client

…

Every MCP server speaks this same lifecycle: negotiate capabilities, discover what is available, then call it. That sameness is why one client can talk to any server.