Closing the Rendering Gap
HPAA turns a familiar moderation assumption into an architectural requirement: a system should not judge only the representation that its detector happens to receive if the platform will show a richer representation to a person. This chapter translates that requirement into a layered defensive design, using Unicode security mechanisms where their assumptions fit and retaining semantic moderation where they do not. The practical outcome is a way to compare views, choose calibrated responses, and test the residual gap without relying on a single cleanup rule.
Make the representation boundary observable
The first defensive move is to stop treating “the text” as one undifferentiated object. A moderation service should be able to distinguish, at least conceptually, the submitted form, the representation sent to automated analysis, and the form that the platform will render to a recipient. The exact data model will vary by service, but the security question is stable: what information crosses each boundary, and can an investigator later show what the detector and the user actually received?
This does not mean storing every possible intermediate artifact forever or making one representation authoritative for every purpose. It means defining the contracts between intake, rendering, classification, policy, and review. Intake should record which characters and formatting features the platform accepts. The representation layer should document any normalization, flattening, or filtering before classification. The rendering layer should make clear how the accepted content will appear to a recipient. The moderation decision should be tied to the representation and policy state that produced it.
A useful defensive pipeline begins with parallel views rather than a single flattened string:
- Capture the accepted submission. Preserve the information needed to understand what the user sent and what the platform agreed to display.
- Derive a comparison form. Apply documented Unicode and syntax processing so equivalent or suspiciously ambiguous forms can be compared consistently.
- Inspect presentation semantics. Identify formatting, spatial, emphasis, or other display features that may affect what a person notices or groups together.
- Run semantic moderation with those signals available. A toxicity classifier still has to reason about meaning and context, but it should not be asked to infer every display cue from a representation that has already discarded it.
- Route uncertainty deliberately. A material disagreement between the human-visible and detector-facing views can be a reason to hold, warn, or escalate rather than silently release the rendered message.
The first two steps are where UTS #39 offers the clearest defensive vocabulary. Its General Security Profile can restrict or flag characters in identifiers, while normalization and canonical-equivalence checks help prevent equivalent forms from receiving inconsistent treatment. Confusable skeletons, script diagnostics, mixed-number checks, and related signals can identify possible ambiguity. These mechanisms are useful when a service is handling names, URLs, account identifiers, or other strings whose identity must be stable.
For general user-generated prose, the same signals should be treated as evidence about representation, not as a complete policy label. A mixed-script or confusable warning does not establish that a sentence is harmful. A restricted character does not prove malicious intent. A normalized comparison form does not reveal whether emphasis or spatial grouping changes what a reader understands.