← Back to products
AI safety · RedShield × TingLan dual engine

YanAn

Risk is scored while the answer is being written. RedShield (红盾) gives a risk score at every step and cuts the output off when it crosses the line you set; TingLan (听澜) watches word-level cues inside the model and cuts the output off before the risky content is ever spoken. Both engines run in parallel and leave a reviewable record.

YanAn is a runtime safety system for AI services. The main model's weights are unchanged: YanAn reads the signals produced while the answer is being generated and decides whether output that has not yet been released goes out or stops. What counts as out of bounds, and how strict the alarm is, are yours to define. A hosted API and an on-premises appliance ship the same core.

Three locks, all of them working, all of them with a blind spot

Checks today sit in three places: screen the question, match the text against a word list, review the finished answer. Each is effective, and each has a blind spot you can name in advance.

A reviewer at a desk reading a checklist page, with four open boxes in front of her — blue striped, orange, green and cream — each holding a copy of the same warning notice
One notice, four different wrappings. The same blocked intent arrives in many forms, which is why a word list is either loose enough to let one through or tight enough to intercept ordinary questions.

Screening the question

The entry point sees the question and nothing of the several hundred words that follow. A request dressed as fiction, translation or academic work reads as entirely normal at the door; the problem appears halfway through the answer.

Matching against a word list

One blocked intent has many spellings: switch language, split characters into components or pinyin, use homophones, agree on a code with the model first, adopt a different persona, keep two turns normal and raise the real intent on the third. A loose list misses; a tight one over-blocks.

Reviewing the finished answer

Judging after the last word means the user may already have read it. Retracting an answer that is on screen costs the service provider, and it does not recall the part that was seen.

The blind spot all three share

The reviewing model and the generating model read the same finished text and may share the same judgment habits, so a single passage can slip past both. Closing that gap takes a different kind of evidence — the signals the model produces while it runs, not only the answer it prints.

Two reviewers side by side reading identical copies of the same finished report, with a closed folder of working drafts on the desk between them
Two reviewers, one finished text, the working draft between them left unopened. Reading the same output a second time does not add a second kind of evidence.

The check keeps pace with generation, and stops mid-sentence

YanAn produces a risk judgment at every step of generation. When the score crosses the line you set, output stops immediately, the remainder stays on the server, and the user gets a clear message. Every step carries a chance to check, and content reaches the screen only after it passes.

One answer, two places to check The answer streams out token by token, left to right Check after it ends the full text goes out first ✓ check By the time it runs, the user has read all of it YanAn scored at every step cut off on crossing risk score threshold held on the server, never released The cutoff lands before that sentence reaches the screen.
Schematic of where the check happens — no time axis and no measured data. The threshold and the handling policy are set by your own business rules.

After a cutoff, the trigger, the score at that moment and the associated cues are written to the record together, so the safety team can review what happened. Alerting, pausing and handoff to a person are configured to your requirements.

RedShield scores, TingLan reads the cues

Both engines read the same running signals in parallel. RedShield returns a comparable risk score; TingLan returns readable word-level cues. Either one crossing the line you set triggers a cutoff.

RedShield 红盾 · the scoring engine

A comparable risk score at every generation step, computed from signals the main model has already produced. The model is not asked to write a review of its own answer, and no second generative reviewer of comparable size has to be stood up.

When the score crosses the threshold, output stops, the unreleased remainder is not sent, and the trigger is recorded. Ordinary answers continue at full speed.

TingLan 听澜 · the cue engine

An answer can be perfectly well phrased and still leave cues worth a look inside. In a government service exchange, the printed answer may never say "address", "phone number" or "ID number", while the internal cues still flag whether the reply touches another person's private data.

Word-level cues have to be read in context; surfacing a cue is not proof of intent. When the cues cross the line you set, TingLan triggers the same cutoff — the risky content is stopped before it is ever spoken. The cues, with their context, then go to a human reviewer who decides whether the answer actually crossed a line.

Each step adds one check of fixed cost

Have a second model re-read the whole prefix after every token and the duplicated work piles up as the answer grows. YanAn reuses the signals the main model has already computed and performs one incremental check per step — so as the answer gets longer, the added cost of each check stays constant.

Two panels. Left: an analyst re-reading an open volume between two tall stacks of tagged paper. Right: the same analyst at a screen showing a short list of three flagged items
Left: re-reading everything from the beginning each time the stack grows. Right: reading only what has just been added. The first gets slower as the stack grows; the second does not.
Added cost of one check as the answer grows Schematic — shape only, no measured values and no scale added cost of one check length of the answer so far a second model re-reads the whole answer each step YanAn · fixed cost per step The longer the answer runs, the wider the gap.
Schematic of the principle, not measured proportions. Model and checking configuration held fixed; only the added checking cost is compared, excluding the main model's own generation.

Adaptation training costs roughly two orders of magnitude less, so when an industry's requirements change, rules and configuration are updated as needed rather than rebuilt. Acceptance rests on three numbers: added cost per thousand requests, added waiting time on the answer, and the request volume your existing resources can carry.

Four places where YanAn is worth evaluating

Organizations running their own LLM

Every outward-facing answer carries service availability and brand exposure, so a dependable check belongs in front of release.

AI service desks that touch personal data

Handling a case means handling personal records; privacy boundaries and public-opinion exposure have to be settled before content reaches the screen.

High-volume consumer applications

Many topics, many rules, a very large number of checks — the cost of a single check sets the long-run cost of running the service.

Agents that take real actions

They send messages, place orders and modify data, so a mistake becomes a real action. Alongside the cutoff, a permission check belongs in front of execution.

Two delivery forms, one core

Both forms ship the same YanAn core. The internal dual engine requires the integration conditions to be met; for a third-party closed-source API, integration normally takes the input/output checking form.

Hosted · API

Call the YanAn service directly, billed by usage. Suited to a POC and to starting at low traffic, confirming the result on your own live questions first.

On-premises · appliance

The whole system runs inside your environment, data stays on the internal network, and adaptation and operations handover are included. One-time delivery plus annual service.

Four steps to production, any of them abortable

Start on a narrow slice, then open up. Every step has a defined acceptance artifact, every step can be stopped, and every step is judged on the same three numbers: how much risk was missed, how many ordinary questions were intercepted, and how much extra time and resource it cost.

Two colleagues at a desk reviewing a dashboard on a laptop while one of them marks up a printed checklist
Every step is read the same way: the monitoring view on one side, the acceptance artifact on the other.

01 · Shadow run

Monitor only, intercept nothing, and see which answers would raise an alert. Acceptance artifact: a missed-risk and false-interception comparison report.

02 · Tune to your policy

Adjust rules and thresholds to your requirements to bring down both missed risks and false interceptions. Acceptance artifact: a build tuned to your policy.

03 · Turn on live interception

Enable the cutoff at low traffic first and test speed, the user-facing message and handoff to a person. Acceptance artifact: production thresholds and a contingency plan.

04 · Full traffic, ongoing

Once it holds, widen to full traffic and keep the business rules current. Acceptance artifact: full-traffic operation plus annual service.

Deployment boundaries: where it sits, what it reads, who decides

Control over the model, the data and the rules stays with you. Deployment, logging scope and interception behaviour are written into the delivery plan.

Main model weights unchanged

The main model keeps its full capability; YanAn can be disabled or removed under the plan.

Read-only signals, unreleased output

YanAn reads running signals, and what it controls is content that has not yet gone to the user.

On-premises, data on your network

The on-premises build runs in your environment, with logs retained locally as agreed.

Policy and thresholds are yours

What counts as out of bounds, and how strict the alarm is, follow your business requirements.

A record you can audit

Triggers, associated cues and handling outcomes are retained for human review.

Nine things your technical team should confirm before deployment

They fall on three lines: integration, running cost, and how well the checking works; the implementation itself is packaged inside the product. The acceptance principle is one comparison — run the same batch of live questions through your current approach and through YanAn, confirm the checking result first, then compare speed, resource use and cost.

Integration conditions

Confirm whether the existing service can integrate, and pick the integration form.

Running cost

Compare the added cost and resource use per thousand requests.

Waiting time

Check whether the added wait on an answer meets the business requirement.

Checking result

Read missed risks and false interceptions separately, never as a single score.

Real-time cutoff

Confirm that unreleased content actually stops once the score crosses the line.

Policy updates

After a policy update, verify that ordinary questions are unaffected.

Handling policy

Settle how alerts, pauses and handoff to a person are handled.

Review records

Agree what is recorded, how long it is kept, and who can read it.

Delivery form

Hosted API or on-premises deployment, chosen against your data and compliance conditions.

YanAn is now open for trials

Enterprise and government teams: contact us for a demonstration, a shadow run on your own traffic, and a delivery plan. Hosted API and on-premises appliance are both available.

Contact the business team →