Operators still need a surface
A pure API is powerful, but early users often need a way to test files, inspect outputs, and download artifacts without writing code. The processor exists for that reason.
The processor is intentionally narrow. It is not a CRM, AMS, underwriting workbench, claims system, or policy admin tool. It is a document-processing surface on top of the same backend contract.
Same result, different entry point
Whether a document arrives through API, processor, playground, intake, MCP, or CLI, the result should go through FastScript. That keeps behavior consistent across surfaces.
This is important for trust. The operator preview and the developer integration should not disagree because they used different logic paths.
Why narrow is strategic
Workflow suites are tempting, but they create scope creep and channel conflict. PolDex wins by being the rail that other systems use, not by replacing every system.
A narrow processor supports adoption without changing the company boundary. It helps customers test and review while preserving the API-first product shape.