Ownership and boundaries

The application composition root creates one ErrorManager, configures its policy roles, and connects the runtime boundaries it owns. The manager has no static current instance and is not a dependency to resolve inside a feature.

Application composition root
  ├── root Zone
  ├── child-isolate bindings
  ├── optional Flutter binding
  └── ErrorManager
        ├── Classifiers and Context Providers
        ├── Policy and Sanitizer
        └── Reporters, Presenter, and Recovery

UseCases, Presenters, repositories, DataSources, and services continue to use normal propagation. Expected failures remain in their typed API. Unexpected failures reach a root boundary because they were not recovered locally.

Three honest outcomes at a local boundary

When code catches an error, it must choose one outcome:

1. recover locally and do not report it globally;
2. transform or rethrow it so normal propagation continues;
3. deliberately submit it once through handleError or captureError.

Injecting the manager into every object would obscure that decision, couple business code to runtime infrastructure, and make duplicate reporting likely.

Centralized is not global

Centralized ownership means one application object controls the pipeline. Global access would mean arbitrary code can retrieve that object from anywhere. Ark Error Manager provides the first model and deliberately excludes the second.