Core Concepts and Architecture

Overview

Bloqr Systems organizes policy-driven AI protection around a small set of core ideas: requests enter a filtering pipeline, rules evaluate the content, and observability data helps you understand what happened and why. This starter-kit page gives you a practical mental model you can adapt to your own product and deployment.

At a high level, you can think about the system as four layers: input, policy, decision, and telemetry. Each layer is intentionally narrow so you can change one part without rewriting the others. That separation also makes it easier to test policy changes before you apply them broadly.

Core Concepts

Policy

A policy is the top-level configuration object that groups related rules and defines the action to take when a condition matches. In practice, you usually split policies by tenant, environment, route, or workload.

Filter

A filter is the execution path that inspects a request. It can normalize the input, score it, and decide whether to allow, block, redact, or forward it for further review.

Rule

A rule is the smallest decision unit. Rules usually check one thing at a time, such as a keyword pattern, a confidence threshold, or a user context attribute.

Telemetry

Telemetry gives you visibility into what the system did. You typically record a request identifier, matched rules, latency, and the final outcome so you can audit changes over time.

Request and Policy Flow

A simple request flow often looks like this:

What the flow optimizes for

You want the flow to be fast, explainable, and easy to observe. Fast decisions keep your application responsive. Explainable decisions help your team understand why a request was blocked or transformed. Observable decisions let you detect regressions when policy changes roll out.

Rule Evaluation Lifecycle

const request = {
  id: "req_8f31c2",
  tenant: "acme",
  route: "chat.completions",
  content: "Please summarize the attached policy document."
};

const evaluation = await client.evaluate(request);

console.log(evaluation.decision);
console.log(evaluation.matchedRules);

request = {
    "id": "req_8f31c2",
    "tenant": "acme",
    "route": "chat.completions",
    "content": "Please summarize the attached policy document."
}

evaluation = client.evaluate(request)

print(evaluation.decision)
print(evaluation.matched_rules)

A rule evaluation lifecycle commonly includes these stages:

1. Parse the request and extract the fields you need.
2. Run normalization so the same content produces the same signals.
3. Match the request against active policy rules.
4. Produce a decision and optional remediation details.
5. Emit structured telemetry for audit and analysis.

Example decision fields

Observability Model

Observability is the control plane for your policy system. It tells you whether the filter is healthy, which rules are active, and how often each outcome occurs. If you only track blocked requests, you miss the baseline that helps you spot drift.

Use three signals together:

• Logs for event-level detail and troubleshooting.
• Metrics for trends, rates, and alerting.
• Traces for end-to-end timing across the request path.

Recommended dashboard signals

Platform Approaches

const result = await client.filter({
  tenant: "acme",
  content: "Draft a customer support reply."
});

if (result.decision === "block") {
  throw new Error("Content rejected by policy");
}

const result = await client.queueReview({
  tenant: "acme",
  content: "Draft a customer support reply."
});

console.log(result.reviewId);

await client.publishDecision({
  tenant: "acme",
  decision: "allow",
  requestId: "req_8f31c2"
});

Best Practices

Next Steps

Use this architecture model to map your own product concepts into a clean documentation structure. Once you define your policy vocabulary and telemetry fields, you can extend this page with concrete endpoints, sample payloads, and operational guides.