Sanitisation belongs to a boundary

Policy placement

The message-processing pipeline supports sanitisation after input transformation and during output preparation. Input policy governs the representation passed to logging and release handling. Output policy governs the representation permitted for a particular destination.

Validation establishes whether a message satisfies structural and content requirements. Sanitisation applies the configured field policy; authorisation controls release. Each operation requires a defined position in the processing path.

Destination policy example

A synthetic input contains an observation identifier, timestamp and optional operator comment. Input policy removes the comment before logging. An applicable output profile removes the observation identifier while preserving mandatory fields for its format.

The held-release preview represents the sanitised payload prepared for export, allowing the approval decision to refer to the content selected for transmission. The example uses fictional fields.

Each destination requires an independently prepared result. Transforming one output must not alter another output's representation. Regression tests should check this isolation directly.

Representation comparison

Received input:
{"observationId":"demo-1","time":"example-time","comment":"internal-example"}

After input policy, before later logging:
{"observationId":"demo-1","time":"example-time"}

Prepared release preview and transmitted representation:
{"time":"example-time"}

The relevant assertions compare the later logging representation with the input-policy result, then compare the release preview and decoded outbound payload with the destination-policy result. A serialization success alone cannot establish these properties.

A separate typed XML example provides four executable preservation and redaction tests. It verifies semantic equality and absence of the excluded attribute while checking that source data remains unchanged.

Unmapped traffic and profile failures

Profile resolution distinguishes an absent format mapping, an incompatible profile and an execution failure. Unmapped traffic follows the configured pass, quarantine or block action.

Profile execution failures must remain observable. Profile validation also protects required fields and checks format eligibility before a transformation is treated as applicable.

Policy resolution

I placed output format mappings on active connectors, removing repeated repository collection scans from policy resolution. Direct-output and held-release paths use a shared resolver to select the applicable policy before execution.

Consistency tests can compare the action selected for the same format and settings on both paths. Configuration updates also require a defined activation point for existing connectors.

Verification requirements

• A removed input field does not appear in the later logging representation.
• The held preview and prepared outbound content agree.
• Required fields survive a permitted transformation.
• Unmapped traffic follows the configured action, and profile execution failure is observable.
• Preparing one destination does not contaminate another destination's result.

The documented tests inspect processing with fake connections and compare sanitised release previews with payloads delivered over local sockets. The socket fixture substitutes a test signer and therefore excludes production signing correctness.

Related reading: the processing flow and testing at application boundaries.