Language Safety

Every string that Amal renders to a user, saves to the database, or includes in a printed report passes through a language-safety filter before it reaches its destination. This is not an optional moderation layer; it is a mandatory step in the render pipeline. A string that cannot be safely filtered does not display. The platform fails closed rather than emit unfiltered text.

The filter does two things. It converts deficit and clinical phrasing to growth language. And it removes any label drawn from international assessment frameworks or clinical classification systems, none of which belong in copy that a teacher, parent, or student reads.

Why growth language matters

A reading platform for children carries a genuine risk: if the words used to describe a child’s reading picture signal deficit, the message a teacher or parent takes away may be more damaging than helpful. Terms that carry clinical weight in research literature do not belong on a screen a teacher reads to a parent or a notification a parent opens on their phone. The filter converts such terms to their growth equivalents before they appear anywhere in the product.

This is not euphemism. The goal is specificity and forward focus. A status that says “this skill needs more practice” is more actionable than a label, and it is accurate: it reflects what the data shows without overstating certainty.

How the filter works

When the platform needs to render a string for a specific audience, it loads the active rule set for that audience tier and applies the rules in a fixed, stable order:

Each rule has a severity: some replace problematic text with a safer alternative, some soften phrasing, and some strip the problematic element entirely. Rules apply to specific audience tiers, so a rule for the parent audience does not run against teacher-only copy.

The filter runs in process, not via a network call, so there is no latency hit and no failure mode where an external service being down causes the render to fail.

Audience tiers

Four tiers determine which rules apply:

Teacher and admin tier. The full filter runs: clinical-term replacement, framework-label removal, and categorical softening. This tier covers dashboard text, alert messages, narrative summaries, and admin-facing reports.

Parent tier. All of the above, plus parent-specific growth-language scripts that have been reviewed for tone and accessibility to non-specialist readers.

Parent stricter tier. All of the above, plus: no numeric scores may appear, no internal profile or bundle identifiers may appear, and five specific Arabic deficit phrases identified by the platform’s educational partner are blocked. This tier applies to any text that reaches a parent through a printed report or a shared PDF.

Student tier. A separate filter path designed for the student experience: no peer comparisons, no benchmark labels, and feedback constrained to supportive, task-focused copy.

The per-profile overlay

Each primary reading profile the platform assigns to a student has an associated list of phrases that should never appear in the student’s narrative output, because those phrases would contradict or undermine the growth framing of that specific profile. At render time, the active list for the student’s current profile is loaded and added as an additional overlay on top of the standard rules.

This is why the same filter can produce different outputs for two students in the same audience tier: the base rules are the same, but the per-profile overlay differs. The difference is always in the direction of stricter filtering, never looser.

Rule versioning

Language rules are never edited in place. To update a rule, a new version is inserted and the old version is deactivated. The old version’s row remains permanently. At any point in the past, the exact rule set that was active on a given date can be reconstructed.

Active rules are loaded with a fail-closed behavior: if no active rule set can be found when the engine tries to render, it throws an error rather than proceeding with unfiltered text. This means a misconfiguration surfaces immediately as a rendering failure rather than as an invisible gap.

Context flags: the only way to attach context to a student

There is no free-text field on any student record in Amal. This is a hard rule, not a default. A teacher cannot type a note about a child and have it stored on the server. The reason is specific: free text about children is difficult to govern and easy to misuse, and the platform’s educational partner confirmed that controlled flags capture all the context that genuinely affects instruction.

The only way a teacher can record context about a student is by selecting a flag from a closed dictionary. Seven flags are currently allowed:

Three additional flag categories are explicitly blocked: general free-text notes, medical notes, and psychological notes. Attempting to submit one of these returns an error. The system records the fact that a blocked flag was attempted and the length of the value that was submitted, but the value itself is never stored.

This blocking is not advisory. It is enforced in the handler. There is no override path and no admin bypass.

What this means for reports

Every piece of text that appears in a teacher’s dashboard, a parent’s notification, a PDF report, or a principal’s school view has passed through the language-safety layer. The layer runs at write time for stored text and at render time for dynamically assembled copy. There is no surface where raw, unfiltered text from the internal decision pipeline can reach a user.

Where to go next

• Quality & Determinism describes how the platform ensures that decisions are repeatable and the checks that guard against silent errors.
• Language Safety (technical reference) covers the full rule pipeline and the flag dictionary in the detail needed to evaluate or configure it.