Why Red-Line Checks Must Run before Any AI Model: the SAR Pre-Check Architecture

# Why Red-Line Checks Must Run before Any AI Model: the SAR Pre-Check Architecture

Direct Answer

In an AI-based fault-diagnosis pipeline, the SAR red lines are not "one more verification step" — they are a hard gate that must run before all model computation. Their job is not scoring or prediction; it is answering one question with five national-standard bottom lines: "is there immediate danger?" When any red line triggers, the system immediately outputs the highest-level alarm (BJ2) and skips all weighted computation — because a red-line trigger means immediate risk to people and property, and there is no room for "let us compute first, then decide."

For platform architects and pre-sales engineers, this article explains three things: why red lines and weighted analysis must be separate layers with red lines first; what each of the five SAR red lines protects against and which national standard it references; and how to verify that a system really implements the red lines "up front." The example of "a campus distribution system" is used for illustration and does not refer to any specific project.

Red Lines and Weighted Analysis Are Different in Kind

Most confusion comes from treating the two mechanisms as the same thing:

• Weighted analysis answers "how severe?" It combines voltage, current, temperature, leakage, and other parameters by weight into a 0–100 risk score. Its output is a continuous value with confidence, allowing faults to be ranked against each other.
• Red lines answer "must we stop now?" This is a boolean check concerned only with whether a national-standard bottom line has been touched. There are two outputs: triggered, not triggered. There is no "almost triggered" middle state.

Putting both in the same layer and processing them in one flow creates an unacceptable risk: a weighted result of 42 (between YJ2 and BJ1) can produce a "handle within 48 hours" recommendation, but if residual current has already reached 300 mA — the weighted score may be diluted by other healthy parameters — following the weighted result misses the immediate danger.

That is the reason for layering: bottom-line judgments leave no room for negotiation and must exist independently of any weighted logic.

The Five SAR Red Lines and Their Standard Basis

There are five SAR (pre-check) red lines, all mapped to national-standard bottom-line scenarios:

These five cover the most typical "immediate-danger" scenarios in electrical safety: leakage, earthing failure, voltage unbalance, overheating, and insulation degradation. Their defining property: once any of them holds, the danger is certain and requires immediate action regardless of every other parameter — exactly the qualification for a hard rule.

The Pre-Gate: Triggering before Model Computation

The pipeline execution order is not "models first, rules afterwards" but the reverse:

1. L1 ingestion: sensor data enters the platform (40+ protocols).
2. L2 cleansing: four-level cleansing removes bad data and aligns timestamps.
3. L3 standard check (SAR red-line pre-check): before Qianzhi's sub-models run, the five red lines are evaluated one by one. Any trigger → output BJ2 directly, skip all weighted computation, and move to L7 persistence and push; none triggered → release to L4.
4. L4 Qianzhi analysis: 50 sub-models run in parallel for parameter sensing and scoring (about 800 ms).

This order guarantees one thing: red-line evaluation consumes a fixed, minimal amount of computation, and its response time does not grow with model complexity. The "stop immediately" recommendation on a red-line trigger depends on a direct path, not a whole model chain.

Why No One Can Raise the Red-Line Thresholds

The system design carries two hard constraints:

• Thresholds are not adjustable. No interface allows operations staff or administrators to modify the five red-line thresholds. Values such as 300 mA per the GB 13955 framework are safety bottom lines, not tunable parameters.
• No one may relax them — including platform administrators. The reasoning is direct: if "raise 300 mA to 500 mA to reduce alarms" were allowed, the red line would degrade from a safety bottom line into a business preference and lose its reason to exist.

This contrasts with how ordinary alarm thresholds are managed: normal parameter thresholds can be adjusted per operating condition (for example, a temperature alarm from 85 °C to 90 °C) because that is part of operational experience; red-line thresholds are bound to national standards and constitute a non-negotiable safety contract. Once adjustable, the system would be allowed to "discount" safety.

Gate First vs Compute First

The difference between the two architectures is best shown with a scenario. A campus distribution system sees a sudden rise in residual current late at night:

• Compute first, gate later (wrong): the model chain runs to completion and yields a composite risk score of 55 (YJ1 tier, "review within 48 hours"); then the rule layer notices residual current has hit 300 mA and escalates to the top tier. Problems: extra model latency (milliseconds to seconds), and an intermediate conclusion of "risk 55" that is actively misleading — a duty operator may act on the lower-tier alarm first.
• Gate first, compute later (SAR architecture): L3 hits SAR-01 directly and immediately emits BJ2 without any intermediate tiering. The alarm semantics are single, the path is shortest, and the conclusion is unambiguous.

The core difference is not latency (both finish within seconds) but the purity of the conclusion: a front-loaded red line guarantees that "immediate danger" alarms always appear in their most direct form, un-polluted and undelayed by intermediate results.

Where the Pre-Check Sits in the Pipeline

In the full seven-level pipeline, the SAR pre-check is L3:

L1 ingestion → L2 cleansing → L3 standard check (SAR pre-check) → L4 Qianzhi analysis (50 parallel sub-models) → L5 Wanxiang reasoning → L6 fusion decision → L7 persistence (dual-store, real-time push, triggering Tianyuan prediction)

In terms of responsibility:

• L1–L2 prepare data; they do not judge.
• L3 is the "safety gate"; it only answers "is there immediate danger?"
• L4–L6 form the "analysis engine"; they answer "how severe, what type, how to handle."
• L7 is the "output channel" that persists alarms, predictions, and history.

The "front" in front-loaded is not a positional convenience but a safety-semantic necessity: only by placing the gate before analysis can we guarantee that no analysis conclusion can override a bottom-line judgment. In a red-line-trigger scenario, model scores of 55 or 88 should never have a chance to reach the user.

The Boundary between Rules and Models

After layering, the division of labor becomes clear:

The selection rule can be summarized as: judgments that are "dangerous the moment they hold" go to rules; judgments that "need to explain degree and cause" go to models. Hard-coding rules into model weights is a common mistake — a model can give 92% confidence, but confidence, however high, cannot replace the determinate conclusion that "300 mA demands immediate action."

How to Verify That the Red Lines Really Run First

For an owner or integrator, four checkpoints can verify that a system truly front-loads its red lines:

1. Timing check: inject a red-line-triggering sample and verify that alarm generation time is decoupled from model computation (the red-line alarm must not wait for the full model chain).
2. Threshold-lock check: attempt to modify any red-line threshold through any interface — it should be rejected; modifying an ordinary alarm threshold should work normally. The two paths must behave differently.
3. Intermediate-conclusion check: in a red-line scenario, the system must not first emit a low-tier risk score (such as 55) and then escalate; the alarm should appear directly at the highest tier.
4. Priority check: construct data where all other parameters are healthy but one red line triggers; confirm the red line still fires on its own rather than being diluted by other parameters.

Only when all four pass can the red lines be said to be truly "front-loaded" — not just a sentence in a design document.

Scope and Limitations

This is the reading page for KD-0012. The five SAR red lines and their standard references come from the FEXLINK product knowledge base (SAR red-line guard, five non-bypassable rules); the standard numbers follow the knowledge-base convention, and the specific clauses and currently effective editions follow the standards themselves. "No one may raise the thresholds" is a platform design convention. The "campus distribution system" is a desensitized illustration. Front-loading red lines solves the "bottom line cannot be overridden" problem but does not replace site procedures: the "stop immediately" recommendation is a handling suggestion, and actual execution still requires safety procedures and human judgment. Medium- and low-risk cases outside the red lines still rely on the Qianzhi, Wanxiang, and Tianyuan analysis chain. The 408-standard library (GB/GB-T/DL/IEC/UL and other 12 systems) is a product-documentation statement.