Dictation Scope Guard
Component Detail
Description
A policy-enforcement service that validates whether dictation is permitted in the current application context. Implements the explicit business rule that audio capture is only allowed in post-activity report fields, never during an active peer mentoring session or in unapproved screens. Blindeforbundet's prohibition on in-session recording is enforced here.
dictation-scope-guard
Summaries
The Dictation Scope Guard directly protects the organization from legal and reputational risk by enforcing Blindeforbundet's explicit prohibition on audio recording during live peer mentoring sessions. Without this safeguard, the application could inadvertently capture private conversations between vulnerable individuals, exposing the organization to serious privacy violations and eroding the trust of both volunteers and the people they serve. By encoding this policy into a dedicated enforcement layer rather than relying on developer discipline, the organization gains a reliable compliance guarantee that survives staff turnover and future feature development. This component transforms a sensitive organizational commitment into a durable technical constraint, protecting users and the brand simultaneously.
This is a low-complexity component with zero external dependencies, making it one of the safest deliverables on the schedule. Development effort is minimal — the core logic is a policy lookup table against approved route and field IDs — but it is a hard prerequisite for any dictation-enabled screen before QA sign-off. Testing must cover all prohibited contexts (active session screens, unapproved fields) and all approved contexts, with explicit verification of the audit log on prohibited attempts. The main scheduling risk is upstream: the list of approved route IDs must be finalized with product and legal before implementation is complete, so that dependency must be tracked.
Plan for a short review cycle with the client to confirm the scope map.
Dictation Scope Guard is a stateless policy service operating exclusively in the mobile execution context. Its core data structure is a configuration map (routeId → Set
No dependencies are declared; the component is self-contained and should be injected as a singleton via the DI container so the approved-context map is stable across the app lifecycle. Audit logging on prohibited attempts must write to the same structured log sink used by other security-sensitive paths. Keep the config map immutable after initialization; mutations should go through the register/revoke API to ensure log coverage.
Responsibilities
- Evaluate whether the current screen and field are approved dictation contexts
- Prevent dictation initiation in prohibited contexts with a clear user-facing explanation
- Provide a configuration map of approved field IDs and screen routes for dictation
- Log any attempt to initiate dictation in a prohibited context for audit purposes
Interfaces
isDictationAllowed(FieldContext context)
getProhibitionReason(FieldContext context)
registerApprovedContext(String routeId, List<String> fieldIds)
revokeApprovedContext(String routeId)
Relationships
Used Integrations (1)
External integrations and APIs this component relies on