The objection
A private company that operates the State’s decision systems ends up exercising a power that no one granted it and against which no one has recourse.
The principle
Software does not create public authority.
The objection is legitimate
Whoever builds the system in which an institution makes its decisions acquires a singular position: they define what can be recorded, what can be queried, what can be ordered and what falls outside the reach of the interface. That position is real, and it does not disappear because the contract calls it “software provision.”
The objection is not paranoia. It is the right question, and a company that evades it does not deserve to operate in this field.
The distinction on which the answer rests
That a capability is technically possible does not make it legally valid. The authority to query a piece of data, coordinate an operation or execute an action does not arise from the system that makes it convenient: it arises from a power that a legal norm confers on an institution, with a declared purpose, a bounded scope and a defined duration.
Edelon does not assign powers, does not interpret the law and does not turn administrative or operational privileges into a public mandate. The institution retains its powers, its custodianship and its responsibility; the vendor retains the obligation to ensure that the system permits no more than the authority permitted.
What this demands of the design
Technical support access must be bounded in scope and time, must be recorded and must be distinguishable from ordinary operational access. Exceptional access must exist—systems fail and someone has to repair them—but it must be exceptional in the verifiable sense of the term: limited, temporary and with evidence that it occurred.
That the vendor can maintain the system must not mean that it can see into the operation. That separation is a property of the architecture, not a promise of conduct.
State of the evidence
What follows distinguishes design from demonstration. A principle upheld is not the same as a proven capability, and this series does not use the present tense for the latter.
- DesignedSeparation between maintenance access and operational accessDefined in the architecture of the security platform. No evidence of operation in a real institutional deployment.
- DesignedRecord of exceptional access with scope and durationThe emergency access mechanism is specified; its behavior under external audit has not been demonstrated.
- UnprovenThe vendor cannot expand its own scopeThis is the central constraint of this essay, and today it is a design commitment, not a fact verified by a third party.
Open questions
- Who verifies the constraint when the verifier is the one who hires the vendor? Independent audit is the standard answer, and it is not yet part of Edelon’s operating model.
- What happens if an institution asks the vendor for a capability that exceeds its powers? Refusal must be possible and must be recorded; the procedure has not been formalized.