InputLayer in 10 Minutes: From Docker to Your First Knowledge Graph

InputLayer in 10 Minutes: From Docker to Your First Knowledge Graph

Someone changes a role in your org chart. Now you need to figure out which permissions changed, which documents need re-filtering, and which downstream reports are stale. In custom-built permission systems, that's a ticket, a script, and a prayer that you caught everything.

In 10 minutes, you'll build a knowledge graph that derives conclusions automatically, updates them in real time when facts change, and explains every result with a full reasoning chain. Not a toy demo. These are the same mechanics that handle access control hierarchies, compliance chains, and recommendation graphs in production. Let's build it.

Step 1: Start InputLayer

Run this in your terminal:

docker run -p 8080:8080 ghcr.io/inputlayer/inputlayer

You'll see InputLayer start up and print a message telling you it's ready. That's it. No config files, no setup.

Step 2: Open the REPL

Now you need a way to talk to InputLayer. Open your browser and go to:

http://localhost:8080

This opens InputLayer's interactive REPL, a command line where you can type queries and see results immediately. Think of it like a SQL console, but for knowledge graphs.

You can also use the Python SDK or the REST API, but the REPL is the fastest way to explore.

Step 3: Store some facts

Let's model a small organization. In the REPL, you'll store three facts about who manages whom:

Alice manages Bob
Bob manages Charlie
Bob manages Diana

Here's what that looks like as a structure:

Alice
Bob
Charlie
Diana

That's the entire org chart. Three facts, four people. InputLayer stores these immediately. No schema to define, no tables to create.

You can already ask simple questions: "Who does Bob manage?" returns Charlie and Diana. "Who manages Bob?" returns Alice. These are direct lookups, nothing special yet.

Step 4: Define a rule

This is the step where InputLayer becomes fundamentally different from a regular database.

We want to answer: "Who does Alice have authority over?" Alice manages Bob directly. But does she have authority over Charlie? She doesn't manage Charlie. Bob does. But intuitively, yes, because she manages the person who manages Charlie.

You express this intuition as a rule:

If A manages B, then A has authority over B. If A has authority over B, and B has authority over C, then A has authority over C too.

That second sentence is the important part. It's recursive. It says: authority flows down through the management chain, no matter how deep it goes.

When you enter this rule, InputLayer immediately starts reasoning. It applies the rule over and over until there are no more conclusions to draw. Here's what it figures out:

1

Alice -> Bob

Direct

2

Bob -> Charlie, Diana

Direct

3

Alice -> Charlie

Derived through Bob

4

Alice -> Diana

Derived through Bob

Five authority relationships, derived automatically from three facts and one rule.

Step 5: Ask a question

Now query: "Who does Alice have authority over?"

The answer: Bob, Charlie, and Diana.

Alice doesn't manage Charlie or Diana directly. But the engine followed the chain and derived it automatically. SQL can compute this too, but InputLayer maintains the result in real time. When facts change, conclusions update in milliseconds without re-running the query.

InputLayer supports vector embeddings alongside logical reasoning. You can combine both in a single query.

Say each person has authored some documents, and each document has an embedding vector. You can now ask something that would normally require multiple systems:

"Find documents similar to my query, but only from people that Alice has authority over."

1

Resolve authority

Bob, Charlie, Diana

2

Filter documents

By those authors

3

Rank by similarity

Most relevant first

Reasoning and retrieval, combined in one pass. No separate authorization service, no glue code.

Step 7: See incremental updates

Add a new fact: Diana now manages a new employee, Frank.

Alice
Bob
Charlie
Diana
Frank

Query authority again. Frank shows up in Alice's results immediately, even though you never told the system about Alice's relationship to Frank. The engine derived it: Alice has authority over Diana, Diana manages Frank, therefore Alice has authority over Frank.

The important part: InputLayer didn't recompute everything from scratch. It identified that the new fact only affects a small part of the graph and updated just that. On a 2,000-node graph, this is over 1,600x faster than recomputing everything.

Step 8: See correct retraction

Remove the fact that Bob manages Diana.

Alice
Bob
Charlie

Query authority again. Diana and Frank are gone from Alice's results. But Bob still has authority over Charlie. That relationship doesn't depend on Diana at all.

Here's the subtle part: what if Diana had reported to Alice through two paths? Say both Bob and Eve managed Diana. Removing Bob's management of Diana shouldn't remove Alice's authority over Diana if the Eve path still exists. InputLayer tracks this automatically. A conclusion only disappears when all paths supporting it are gone.

What you just built

In about 10 minutes, you've used:

CapabilityWhat happened
Knowledge graphStored facts about people and relationships
Recursive reasoningA rule derived authority chains automatically
Vector searchCombined similarity with logical reasoning
Incremental updatesNew facts spread in milliseconds
Correct retractionRemoved facts cleaned up precisely

These capabilities often live in separate systems: graph traversal in one, vector search in another, business rules in application code. InputLayer handles them in one place.

Next steps

The data modeling guide covers how to design your knowledge graph schema. The vectors guide dives deeper into similarity search and HNSW indexes. And the Python SDK is the fastest way to integrate InputLayer into your applications.

Ready to get started?

InputLayer is open-source. Pull the Docker image and start building.