Architecture

System Diagram

                         Client Request
                              |
                              v
                    +-------------------+
                    |   Caddy Reverse   |
                    |   Proxy (TLS)     |
                    |  *.tismjedi-      |
                    |  homelab.com      |
                    +-------------------+
                       |      |      |
          +------------+      |      +------------+
          |                   |                   |
          v                   v                   v
+------------------+ +------------------+ +------------------+
|  Security Gate   | |     Router       | |    Verifier      |
|  192.168.0.82    | |  192.168.0.4     | |  192.168.0.50    |
|                  | |                  | |                  |
|  L1: Input Scan  | |  L2: Classify    | |  L4: Verify      |
|  - Rule engine   | |  L3: Execute     | |  - Faithfulness  |
|  - ML classifier | |  - Model select  | |  - Well-formed   |
|  - Behavioral    | |  - Provider mgmt | |  - Security      |
|                  | |  - Cost tracking | |  - Quality       |
+------------------+ +------------------+ +------------------+
        |                     |                   |
        +----------+----------+-------------------+
                   |
                   v
          L5: Attestation Chain
          (linked across all services)

Data Flow

A request moves through the pipeline in a strict sequence. Each stage must complete successfully before the next begins.

1. Input Scanning (Security Gate)

The client sends raw input to the Security Gate. The gate runs a three-stage detection pipeline:

1. Rule-based scanning — pattern matching against known injection signatures, encoding tricks, and structural anomalies
2. ML classifier — a trained model that scores the input for adversarial intent across multiple threat categories
3. Behavioral analysis — examines the input in context for manipulation patterns that individual rules or classifiers might miss (role escalation, multi-turn setup)

If the input passes all three stages, the gate returns a CLEAN verdict with an attestation_id. This attestation is required by the router.

2. Intent Classification (Router)

The router receives the input along with the attestation ID from the gate. It:

• Validates the attestation against the gate
• Classifies the task type (code generation, security analysis, document analysis, etc.)
• Selects the appropriate specialist model based on task requirements
• Chooses the provider with the best cost/capability match

The result is a plan — a structured execution strategy with one or more tasks, each assigned to a specific model and provider.

3. Execution (Router)

The router executes the plan by dispatching each task to its assigned model provider. It manages:

• API authentication per provider
• Context window management
• Token usage tracking
• Cost accounting
• Timeout and retry logic

Each task execution produces a result with metadata (tokens used, cost, elapsed time).

4. Output Verification (Verifier)

The completed response is sent to the Verifier along with the original request and domain context. The Verifier uses a different model than the one that generated the response and evaluates it across four axes:

• Faithfulness — does the response accurately address the request?
• Well-formedness — is the output structurally correct for its type?
• Security — does the response contain information leakage, embedded attacks, or policy violations?
• Quality — is the response useful, complete, and appropriate?

The Verifier returns a PASS or FAIL verdict with per-axis scores and reasoning.

5. Attestation Chain

Every service contributes to the attestation chain:

gate_attestation_id  -->  router_plan_id  -->  verifier_result_id
        |                       |                       |
   input_hash              task_results           axis_scores
   threat_scan             model_used             verdict
   scan_time               tokens/cost            confidence

The chain is traceable end-to-end. Given any attestation ID, you can reconstruct the full history of a request.

Microservices Topology

All three services run as lightweight processes inside Proxmox LXC containers on a homelab cluster.

Service	Host	Container	Port	External URL
Security Gate	192.168.0.82	lxc-gate	3001	gate.tismjedi-homelab.com
Router	192.168.0.4	lxc-router	3002	router.tismjedi-homelab.com
Verifier	192.168.0.50	lxc-verifier	3003	verifier.tismjedi-homelab.com

Caddy Reverse Proxy

Caddy handles TLS termination using Cloudflare DNS challenge for wildcard certificates (*.tismjedi-homelab.com). All external traffic is HTTPS. Internal traffic between services uses plain HTTP over the local network.

# Simplified Caddyfile structure
gate.tismjedi-homelab.com {
    reverse_proxy 192.168.0.82:3001
    tls {
        dns cloudflare {env.CF_API_TOKEN}
    }
}

router.tismjedi-homelab.com {
    reverse_proxy 192.168.0.4:3002
    tls {
        dns cloudflare {env.CF_API_TOKEN}
    }
}

verifier.tismjedi-homelab.com {
    reverse_proxy 192.168.0.50:3003
    tls {
        dns cloudflare {env.CF_API_TOKEN}
    }
}

Inter-Service Communication

Services communicate directly over the local network. The Security Gate is the entry point. The Router calls the Gate to validate attestations and calls the Verifier to check outputs when full-pipeline mode is enabled.

Client --> Caddy --> Gate --> (attestation) --> Router --> (result) --> Verifier
                                                  |
                                                  +--> Model Provider APIs
                                                       (OpenAI, Anthropic,
                                                        Google, OpenRouter)

The Router holds API keys for all model providers. Neither the Gate nor the Verifier communicate with external model APIs directly.