Recommended simple architecture — Policy Manager v1 (Kernel)

---

0. Role

The Policy Manager applies cross-cutting governance rules before and after ARG inference,
without depending on the graph.

It is a standalone kernel that:

• blocks or refocuses out-of-scope requests,
• enforces role and product boundaries,
• constrains what the Context Weaver can propose,
• and guards memory writes defined in the ARG Core.

---

1. Non-negotiable principles

• Pre-Check and Post-Check are mandatory.
• Policy does not route the domain.
  It only authorizes or constrains domain routing.
• Project-configurable, not graph-encoded.
  Rules vary by product/org, but must not be embedded node-by-node.
• Minimal latency.
  It must fit a very short budget and remain faster than the
  Context Weaver.

---

2. Inputs and outputs

Inputs

• raw prompt
• user context
  (role, permissions, org, product)
• active context typologies
  (optional, parametric only)

Outputs

2.1 policy_state

• ALLOW
• ALLOW_WITH_REFOCUS
• RESTRICT
• BLOCK

2.2 policy_constraints

• allowed/forbidden labels
• allowed/forbidden node types
• max budgets
  (hops, depth, complexity caps)

2.3 response_mode

• normal
• prudent
• refocus
• refusal

These outputs are consumed by the online loop in
ARG Core.

---

3. Sub-modules

3.1 Scope & Intent Guard (cheap)

Determines whether the request is:

• inside the agent’s domain scope,
• benignly off-topic,
• incompatible with the user role.

Output

• the base policy_state.

---

3.2 Safety / Content Filter (project-specific)

May include:

• profanity/toxicity filters,
• sensitive categories if the product requires them,
• any disallowed topics defined by the project scope.

For a strictly B2B domain agent, this can remain minimal.

---

3.3 Access Control Engine

Implements RBAC/ABAC:

• maps role → allowed labels and node types,
• enforces org/product boundaries.

Output

• policy_constraints.

---

3.4 Response Shaper

Controls:

• refocus style
• refusal templates
• politeness level
• expected format
  (short/long/justified)

---

3.5 Memory Guard (critical)

Controls what can be written to memory:

• blocks PII,
• blocks out-of-scope content,
• enforces scope rules
  (User / Org / Global)

This guard is mandatory for:

• ARG Core — MemoryWrite
• ARG Core — Info Registry

---

4. Online pipeline

PM-1 Pre-Check (before initial classification)

Goals Decide rapidly whether to:

• stop,
• refocus,
• or continue under constraints.

Outputs

• policy_state
• policy_constraints
• response_mode

Simple rules

• BLOCK → immediate stop
• ALLOW_WITH_REFOCUS → short refocus response + return to domain scope
• RESTRICT → continue but with constraints applied downstream

This stage is referenced by
ARG Core — Step 1.

---

PM-2 Constraint injection

Pass constraints to:

• initial label retrieval
  → ARG Core — Step 2
• taxonomy arbitration
  → ARG Core — Step 3
• neighbor scoring
  → ARG Core — Step 5
• traversal
  → ARG Core — Step 7

Key rule Policy does not replace the Weaver.
It limits the Weaver’s valid choice space.

---

PM-3 Post-Check (before response + before MemoryWrite)

Goals Verify that:

• the response stays within scope,
• the action is authorized,
• the memory write absorbs nothing forbidden.

This stage protects against:

• unsafe generative completion,
• accidental privilege escalation,
• silent memory contamination.

---

5. Latency target

The Policy Manager must remain faster than the
Context Weaver.

In practice:

• PM-1 should be built from:
  • rules
  • dictionaries
  • lightweight classifiers when needed

The only path that can become expensive is an LLM-based safety filter —
which is generally unnecessary for a strict domain agent.

---

6. Relationship with the “Policy” typology

A “Policy” typology may exist, but only to parameterize:

• thresholds
• tone and severity of refocus/refusal
• response budget

Decision logic must stay in the Policy Manager.

This rule is aligned with the typology design guidance in
Guides.

---

7. ARG integration summary

To reflect this architecture in the protocol:

• ARG Core — Step 1
  includes the Policy Pre-Check.
• ARG Core — Steps 2–3
  consume policy_constraints.
• ARG Core — Steps 8–9
  pass through Policy Post-Check.
• ARG Core — Step 10
  is enforced by the Memory Guard.