# Write your reliability rules once. Enforce them in every review.

Let’s say your organization requires every outbound request to go through a client wrapper. The wrapper sets a timeout, applies your required retry policy, and adds the logs and traces your team needs when a request fails.

Now imagine an agent implements a new service and imports the client directly. The code compiles, but the request bypasses the wrapper. It can leave without a timeout, the required retry behavior, or the logs and traces your team relies on.

The requirement to use the wrapper may be documented, but a reviewer still has to know it applies to this service and remember to enforce it during the review. The direct import does not tell a review tool that the wrapper is required.

With MindQL, you write a custom rule that prohibits the direct import. Mindrealm enforces it during every review. Reviewers no longer have to know or remember the rule.

## Some failures are unsafe everywhere

An outbound request without a timeout can wait forever when a service stops responding. Mindrealm can include a rule for that failure because it is unsafe everywhere. The rule does not depend on how an organization designed its software or on its unique requirements.

The wrapper in this example is different. Another organization may have different requirements for their wrapper or use no wrapper at all. Only your team can define when application code must use the wrapper, how long requests may wait, which failures should be retried, and what the wrapper must record.

## Your architecture needs custom rules

A required wrapper is one example. Another may be a service that accesses the database, authorizes the command, and applies your business rules before changing data. If application code imports the database client directly, it bypasses those protections.

No review tool can know that requirement without being told. It comes from your architecture, your specifications, and the way your team has chosen to build software.

MindQL lets you add those requirements as custom rules. Commit them with the code, and Mindrealm enforces them during reviews across your organization’s Go, Python, TypeScript, and Rust codebases.

## Match each requirement to the evidence that can prove it

1. **Failures that are unsafe in almost any codebase belong in Mindrealm’s standard rules.**
2. **Requirements that come from your architecture belong in custom MindQL rules.**
3. **Behavior that only exists while software runs must be verified with integration or end to end tests and monitored with production telemetry.**

A rule can flag a direct client import that violates your wrapper requirement. It cannot prove that the wrapper backs off correctly when a request fails under load or that its timeout is right for the service it calls.

Unit tests can exercise behavior such as error handling and retry limits. Integration tests and end to end tests can verify that the service sends requests through the required wrapper and handles failed requests correctly. [Production telemetry](https://opentelemetry.io/docs/concepts/observability-primer/) shows the timeouts, retries, errors, and latency that occurred after deployment.

Mindrealm reviews test code too. Its standard rules can catch missing tests, tests with no assertions, weak assertions, flaky tests, mock abuse, test pollution, and tests skipped without a stated reason. It cannot prove that a test matches a business requirement nobody wrote down.

Rules, tests, and production telemetry answer different questions. You need all three.

## Write the policy once, enforce it across four languages

For the database policy above, your team writes a custom MindQL rule that prohibits the direct import.

If your services span several languages, you still define the policy once. MindQL lets Mindrealm enforce it in Go, Python, TypeScript, and Rust, so your team does not have to build and maintain a separate version for each language or rely on reviewers to know and remember it.

## Your rules need to cover the whole repository

LLM review tools can inspect only the code that fits within the model’s context window. When a repository is too large, they have to sample files or sections of code. A violation outside that sample can be missed. Reviewing more of the repository also consumes more tokens and may increase usage costs.

Mindrealm’s full scan runs every configured rule over every source file. Your custom rules cover the whole repository, not only the code a model happened to receive.

The findings are deterministic. When the code, configuration, and rule versions stay the same, Mindrealm returns the same findings. Your team can fix the code and repeat the review without the standard changing between passes.

Mindrealm starts with a free trial for seven days, then costs $30 per seat each month with no usage or token fees. Run full scans and repeat reviews as much as you need to. Another pass does not increase your bill.

## Put the rules into every review

> If a reliability requirement matters enough to document, it matters enough to enforce in every review.

Mindrealm’s standard rules catch failures that are unsafe everywhere. MindQL enforces the custom rules your organization adds. Both run during every review. Tests exercise behavior before release, and production telemetry shows what happened after deployment. You need all three: deterministic Mindrealm reviews, tests, and production telemetry. Without MindQL, reviewers have to know which custom rules apply and remember to enforce them during every review. Without tests or telemetry, runtime behavior remains unproven.

[Get early access to Mindrealm.](https://mindrealm.ai/?utm_source=hashnode&utm_campaign=reliability-rules) You’ll have direct access to me, and the reliability standards your team wants Mindrealm to enforce will help shape what I build into MindQL next.