Customization

A governance standard is only useful if it matches the team it governs. A rule that is Critical for a regulated production solution might be noise for a throwaway prototype. Logic Guard makes the ruleset yours: everything is customizable per project, and the customization is stored as sparse overrides, so you only record the differences from the baseline and everything else keeps tracking product defaults.

Enable and disable rules

Any of the 143 baseline rules can be turned off for a project. Disabled rules are removed from the checker entirely, so they never produce a finding and never appear in the counts. This is how you silence a rule that does not apply to how your team builds, without arguing about it on every review.

Reclassify severity

Any rule can be promoted or demoted. A Warning you consider serious can become Critical, so it rises to the top of the report. An Info that clutters your reviews can be demoted or, combined with disabling, removed. Reclassification changes how findings are counted and ranked, so the worst-sections view reflects your priorities rather than the defaults.

Both enable/disable and severity live in the project ruleset, managed from the Rules screen in the web application and available through the API.

Scan strictness

Beyond individual rules, you can set the overall posture of a scan with a strictness level:

Strictness	Behavior
Conservative	Reports only high-confidence, severe findings. When a potential issue is ambiguous or borderline, it is not reported. Favors precision over recall.
Standard	The default balance.
Thorough	Exhaustive. Surfaces every plausible issue, including lower-confidence and minor observations, as long as they are grounded in the artifact. Favors recall over precision.

Use conservative for a fast, high-signal gate on a mature solution. Use thorough for a deep review of something new or before a major release.

Scan context

Sometimes the reviewer needs to know something about your project that the artifacts cannot tell them. Logic Guard lets you attach per-section scan context, a short note that is added to one checker's judgment and no others. For example, on the Workflows section you might add: "Flows prefixed TMP_ are throwaway experiments, do not flag missing descriptions on them." That guidance shapes the Workflows checker without leaking into the Business Rules checker or any other.

Scan context is scoped to a single section, so it stays precise. It never changes which rules run or the output format; it only informs how the checker reasons about that artifact type.

What stays fixed

The rule identifiers, their detection logic, and the output contract are product-managed. You control which rules apply, how severe they are, how aggressively to scan, and what context to add. You do not rewrite the detection prose itself, which keeps findings consistent and comparable across projects and over time.