In Bolex, authorization is not a configuration detail.
The routine may be repetitive. Access still belongs to the person responsible for the portal, the condominium, and the people authorized to operate that information.
Automation reduces repetition; it does not expand permission.
01
The work starts with an authorized connection
Bolex exists because signing into portals, locating documents, checking files, and repeating deliveries every month consumes operational time. Solving that problem does not give the product permission to bypass authentication, reuse access beyond its stated purpose, or reach a condominium that was not authorized.
Every integration must begin with valid credentials and a known scope. When a portal interrupts access, changes its flow, or requires new authentication, that should become an operational event — not a reason to search for an invisible workaround.
02
Retrieval is not payment
The product locates, downloads, validates, and delivers documents within the configured routine. It does not make payments or change data in source systems. This boundary reduces the impact of an error and keeps the financial decision outside automation.
Validation matters because finding a PDF is not enough. The document must match the expected context before delivery, and the history should show what happened during every run.
03
Why the public view stops at sign-in
The public Bolex page presents its proposition and a demonstrative composition. Real operations, condominiums, credentials, and documents remain behind restricted access. This is not missing design; it is part of the product boundary.
As new integrations are added, authorization, traceability, and isolation remain acceptance criteria rather than items deferred to a later stage.