How Iris builds context: the default harness and your own knowledge

How Iris builds context: the default harness and your own knowledge

A general-purpose model knows networking, but not how rConfig works, how your team names devices, or what a good access switch looks like on your network. Iris closes that gap with a context harness: a block of background knowledge rConfig adds to every config analysis, drift narration and compliance narration request. Part of it ships with rConfig. The rest is yours to write, and it’s the single most effective way to make Iris’s answers fit your network.

What goes into a request

flowchart TB
    I["1. Instructions<br/>the feature's role and output format"] --> H
    subgraph H["2. Context harness (budgeted)"]
        B["Built-in networking knowledge<br/>ships with rConfig"]
        C["Your knowledge entries<br/>conventions, golden configs, naming, design"]
    end
    H --> D["3. The data<br/>config, diff or compliance results"]
    D --> Q["4. Your question, if any"]
    Q --> M["Your AI provider"]

1. Instructions tell the model its role (config analyst, change reviewer, compliance auditor) and the shape of its answer.
2. The context harness adds background knowledge, within a fixed budget per feature.
3. The data is what you’re asking about: the config, the diff, or the compliance results. Its limits are separate from the harness budget; see Sizing a local model.
4. Your question, for chat and inline prompts.

Secrets are obfuscated before anything leaves rConfig. The optimisation assistant works differently: it searches an index of rConfig’s documentation for each question instead of using this harness. See Optimization Assistant.

The default harness: rConfig’s built-in knowledge

rConfig ships ten topics of networking knowledge, written to be vendor-neutral and checkable against a config. From V8.4.2 they’re loaded automatically on install and upgrade. Each feature gets the topics relevant to it:

It covers things like trunk native-VLAN mismatches, route redistribution loops, management-plane exposure and the misconfigurations that show up in most networks. It can be read but not changed.

Your layer: knowledge entries

Knowledge entries are where you tell Iris what only your team knows. Each has a title, up to 10,000 characters of content, and one of four categories:

They go into every config analysis, drift and compliance request, under a heading that tells the model to treat them as authoritative for your environment. So when your entry says Loopback0 is the router ID, Iris stops flagging it as unusual and starts flagging devices that do it differently.

How the budget is shared

Each feature has a fixed budget for the harness, in characters:

From V8.4.2 the budget is filled like this:

1. Your entries go first, in category order and then oldest first, into an allowance of at least 40% of the budget. If the built-in knowledge needs less than its share, your entries can use more.
2. An entry that doesn’t fit is left out whole, never cut off mid-sentence, because half a convention can mean the opposite of the whole one.
3. The built-in knowledge fills the rest, most fundamental topics first. If it doesn’t all fit, the topic that crosses the limit is shortened and any after it are left out.
4. If anything was left out or shortened, the model is told so.

Writing entries that work

• Short and specific. One rule or convention per entry, a few sentences long. A 10,000-character entry fits only when the built-in knowledge leaves room, and is dropped whole when it doesn’t.
• Say what to check, not what to think. “Every access port must have a description in the form <user|ap|printer>-<location>” lets Iris spot violations. “Descriptions are important” doesn’t.
• Include the reason. “No SNMP v2c in the DMZ (external audit finding, 2025)” helps the model judge severity.
• Golden configs as config text. Paste the actual block, with placeholders for per-device values, so the model compares like with like.
• Turn off, don’t delete. An entry with is_active set to false stops being used but stays on record.
• Keep the total small. If a feature’s answers start ignoring your conventions, count what you’ve added against its allowance in the table above.

Outside agents don’t use the harness

The harness applies to Iris’s features inside rConfig. Agents connected over MCP (Claude Code, Cursor, Codex) don’t receive it. To give them the same conventions, put them in the agent’s instruction file. See Write the routing down once.

Related reference

• How rConfig grounds AI responses
• Teach the AI your conventions
• Better config analysis
• Sizing a local model