Sensitive coverage and editorial limits
How ErmisAI handles sensitive stories and what it will not do on its own.
ErmisAI marks some stories Sensitive — casualties, political figures, legal proceedings, medical claims, armed conflict. If you are the person who answers for what your masthead publishes, the first thing to know is what that marker is not.
It is not a safety mechanism. It does not hold a story, add an approver, or block anything.
What actually keeps a risky story off your site is the workflow, and it applies to every story equally. No story is ever deliverable without a person composing it and an Owner or Admin approving it — at any confidence score, on any topic, flagged or not. There is no auto-publish path and no confidence threshold that skips a person. (Submission is an extra step only for stories that start in Draft — confidence 85 or above and not flagged sensitive. Sensitive stories, and everything scoring below 85, are materialised straight into In review on compose, so no submit action is ever taken.)
The Sensitive marker is a sorting hint on top of that. Read it as "this one is worth your attention first", not "this one is under control".
What the Sensitive flag actually changes
Three things, and the third only matters if you run monitoring alerts.
| Effect | Where it shows up |
|---|---|
| Editorial priority is set to High when the story is created | The High badge on the feed card; the Priority column and the Urgent / High counter on the editorial board |
| A Sensitive marker is displayed on review surfaces | The red Sensitive badge on the review desk; the Sensitive column (Yes / No) in the queue table; the Sensitive counter on the board |
Monitoring alerts about the story are recorded at severity warning instead of info | The severity value on each entry in the alert history |
The High priority badge is also set automatically for anything the pipeline marks breaking, so a High badge on a feed card does not on its own mean the story was flagged sensitive. The card shows a breaking pill when the story is breaking, but there is no marker at all for sensitive, and priority can also be changed by hand — so a High badge with no breaking pill still tells you nothing definite about a sensitive flag.
There is one further difference, and it is easy to misread. A sensitive story is created in the In review editorial state rather than Draft. Every story scoring below 85 on confidence is created that way too, so the flag only changes the starting state for the high-scoring ones.
Being created in review is not the same as being on the editorial board. The board lists only stories that have a real composed article, so a sensitive story sits in review and invisible to reviewers until somebody in the newsroom opens it and generates the first article.
Two consequences of that starting state catch people out. The author never presses "Submit for review" — the button is disabled because the story is already in review — so the notification that submitting normally sends to Owners and Admins is never sent. And once the article has been composed, the author can no longer edit the headline or body from the story workspace; an in-review story is content-locked there, and only the reviewer can edit it, on the review desk.
What it does not change
The Sensitive flag adds no approver, no second sign-off, no hold, and no delivery block. If your publication risk process depends on one of those, you have to build it out of roles and habits, not out of this flag.
- It does not stop delivery. Once a story is approved, a sensitive one is released to the feed and exposed to your CMS export exactly like any other. Nothing downstream checks the flag.
- It does not require a second approver. Approving is the same single action it always is. There is no dual sign-off anywhere in the product.
- It does not prevent self-approval. An Owner or Admin who wrote the article can approve their own sensitive draft. In a one-person newsroom that is the only way it can work, and the story workspace says as much.
- It does not restrict who can write it. Members compose and refine sensitive stories under exactly the same rules as any other story.
- It does not reach the writing assistant. The flag is not part of the context sent to the model when you compose or refine, so the assistant does not know a story was marked sensitive and does not write differently because of it.
- It does not travel to your CMS. The story export carries the headline, body, category, tags, confidence, breaking flag and source list. It does not carry the sensitive flag, and it does not carry conflicts. A system pulling approved stories has no way to tell.
The one place the flag does leave your newsroom is an alert delivered to a webhook: the alert payload includes it alongside the headline, category, confidence and source names.
Where the flag is visible, and where it is not
| Screen | Sensitive shown? |
|---|---|
| Editorial board (Editorial in the sidebar) | Yes — a Sensitive counter and a Sensitive column |
| Review desk ("Open review" on a board row) | Yes — a red Sensitive badge in the header |
| Feed card | No |
| Story workspace | No |
| CMS export and the story API | No |
Both surfaces that show it are Owner and Admin only. A reporter working a story has no way to see that it was flagged, on any screen.
How a story gets flagged
The AI that writes the first synthesis makes the call. It answers one yes/no question per story, at the moment the story is created out of clustered coverage, working from an instruction that names casualties, political figures, legal proceedings, medical claims, and armed conflict.
That is the whole mechanism. Some consequences follow directly from it:
- No reason is recorded. Nothing anywhere shows which words, which topic, or which outlet caused the flag. The badge is all there is. If you want to know why, you read the story.
- It is a judgement, not a rule. There is no keyword list you can inspect, no category mapping, and no threshold. Two similar stories can be judged differently.
- You cannot set or clear it. There is no control for the sensitive flag anywhere in the product, for any role. If the model missed one, you cannot mark it; if it flagged something harmless, you cannot unflag it.
- The backup coverage is thin. A small keyword check exists as a fallback, but it only runs in one narrow situation and it only recognises English and Greek words. If your newsroom publishes in one of the other eight article languages and the model does not flag a story, nothing else will.
Treat the absence of a Sensitive badge as no information at all. It does not mean a story was checked and cleared. It means the model did not flag it — which is a different statement, and one you should never build a process on.
What sensitive coverage means for your day
Given all of the above, the flag is worth using as a triage aid and nothing more. Practical things you can actually do:
Watch the Sensitive counter on the editorial board. It tells you how many of the articles currently waiting for review were flagged. It is a workload signal, not a queue you can filter — the board has no filters, no sort controls and no search.
Filter the feed by priority. The feed filter bar has an All priority selector with Standard, High and Urgent. Because flagged stories start at High, this is the closest thing to a sensitive filter that exists — remembering that breaking stories land in the same bucket, and that a story's priority can be changed afterwards.
Set priority yourself. The Owner and Priority selects live under Editorial handoff in the story workspace and under Editorial routing on the Editorial review screen; both travel with the article into the queue. Board ordering is fixed at Urgent, then High, then Standard, then most recently updated — so raising priority is the only lever you have over what a reviewer sees first.
Use the decision note. On the review desk, the Decision note field (up to 500 characters) is attached to the article as a feedback note when you Approve or Reject, and it stays visible in the Editorial feedback panel. It is where the reasoning for a call on a sensitive story is recorded. When someone other than the author approves or rejects, the author is notified.
Send it back rather than fixing it silently when the problem is the reporting, not the wording. "Send back to compose" returns the article to Draft so the author can regenerate it. Note that it discards any unsaved edits you have made on the review desk, unlike Approve and Reject, which save them first.
Conflicts between sources are a separate signal from the sensitive flag, with separate limitations. See Confidence, sources and conflicts before you rely on either.
The published AI policy
ErmisAI publishes its position on AI use at ermisai.com/ai-policy. It carries the effective date line "Last updated 25 June 2026" and has seven sections. This is the document to point a lawyer, a board, or a source at.
1. What AI is used for. "ErmisAI may use AI systems to help with: clustering overlapping source coverage, synthesizing articles in your language, compose and refinement workflows inside the story workspace, editorial-assist tasks that remain attached to a reviewed article."
2. What AI is not used for. "ErmisAI is not positioned as: a fully automatic publishing system, a substitute for human review on sensitive or disputed stories, a blanket rights-clearing system for third-party content, an image, audio, or video generation workflow in the current product scope."
3. Source grounding and review. "AI-assisted output remains grounded in monitored source material. Customers are expected to review attribution context, conflicts, confidence signals, and any sensitive flags before publication."
4. Sensitive topics. "Stories involving casualties, political figures, legal proceedings, medical claims, or armed conflict need additional caution. ErmisAI is an editorial support tool and does not replace review on those subjects."
5. Rights and licensed material. "Licensed or partner content may only be used within the scope granted by contract. Training, fine-tuning, or other secondary reuse of licensed material needs explicit written permission rather than assumption."
6. Customer responsibility. "Customers remain responsible for publication choices, legal review, attribution, defamation risk, and any copyright or licensing issues related to their use of the output."
7. Product boundaries. "ErmisAI is a newsroom workflow product with multilingual support. It is editorial-assist software, not autonomous media production infrastructure."
What ErmisAI does not claim
The security page carries a section headed "What we do not claim". Two of its entries bear directly on publication risk, and both are worth quoting to anyone who assumes otherwise:
No prevention of AI editorial errors. The product generates AI articles. These may contain factual errors, misattributions, or incomplete coverage. Editorial review before publication is a design assumption, not an optional step.
No substitute for publisher rights review. Security controls do not address content licensing, attribution rights, or syndication terms. Those are separate legal and commercial matters.
The same section states that ErmisAI holds no SOC 2, ISO 27001 or equivalent certification, runs no public bug bounty, and offers no uptime guarantee on the Free, Plus and Pro plans.
Content rights are a separate agreement
Your ErmisAI subscription is a licence to use the software. It grants no rights over the source material the product monitors, and it is not a syndication agreement. Content licensing, territory, attribution terms, retention and takedown, and any secondary reuse are handled as separate contracts.
If you need rights to republish a partner's material, that conversation starts at ermisai.com/contact, not in the product.
Editorial review and approval
The board, the four decisions, and what each one changes.
Confidence, sources and conflicts
What the signal score is built from, and what it does not prove.
Pipeline phases and editorial states
The two status systems on every card, and how they interact.
Alert rules and notifications
Where alert severity comes from and where notifications land.