Click here to download the full series in PDF format.
At the beginning of this series, we noted that “Sahel” is a gateway, not a state; the shadow of the structure, not its maker. In the second part of the series, we descended to the first cause and said that the structural remedy does not lie in suffocating centralization, but in the centrality of the “protocol” and the decentralization of development. We proposed the “general protocol for smart government” as a digital constitution, from which “unified national platforms” and a “programming environment” with four platforms would emerge, transforming integration into a living marketplace rather than exhausting bilateral understandings.
This third part, however, is not a discussion of scattered tools. It is a technical translation of what was built in the second part: how the “constitution” is turned into a “pulse,” how the “national language” becomes real-time operation, and how “Sahel” becomes capable of displaying the truth as it is, not as it reaches it late or contradictory. The technical system is not merely servers and interfaces; it is the form of the state when it speaks to itself. If the “protocol” does not dictate how technology should behave, technology becomes separate interpretations; and if technology does not translate the “protocol” into operation, the “protocol” remains an imposing document that does not reach people’s lives.
The Interruption of the “Digital Pulse”: When Data Does Not Move with the Event
What most weakens trust in the platform is for a beneficiary to see one thing on their phone screen, while the employee sees something else in their system, and then the beneficiary is asked to believe one and disbelieve the other. This paradox is not a display error or an update defect; it is the result of the absence of a sovereign technical condition: that the state be based on the logic of the event, an Event-Driven State, not on the logic of request and response, a Request/Response State.
Here comes the role of the “general protocol for smart government,” not merely as a language of messages, but as an architecture of interactions. If the “protocol” is truly a constitution, it must include an explicit clause imposing the following: (1) every change in the status of a transaction is a “national event” with a unified Event Schema. (2) Every event must be broadcast immediately when it occurs to those concerned through standard channels, not through periodic updates or delayed synchronization. (3) The source of truth is one: the entity that holds sovereignty over the data produces the event, and it may not be regenerated by inference in another entity.
The “protocol programming environment” then translates this clause into practical operation through its platforms: (1) in the programming guide for inter-entity integration, the rules for event broadcasting, Publish/Subscribe, Delivery Guarantees, retry standards, and idempotency logic are defined so that automation does not become a chaos of repetition. (2) In the guide for entities’ endpoints, no “endpoint” that reflects the status of a particular service is listed unless it is connected to its event log, not to a static record summoned upon request. (3) In the unified national platforms, “Sahel” becomes a receiver of events, not a beggar for updates; it displays status as a real-time effect, not as a delayed story. Thus, the “national digital pulse” is formed not as an incidental improvement, but as a condition of trust: when the event moves, the state moves with it.
Scalability: When the Pulse Is Tested Under Pressure
Because the logic of events naturally multiplies the volume of flows, the transition to an event-driven state cannot be built on the assumption of permanent stability. Crises, seasons, and pivotal decisions are enough to overwhelm any system not designed to withstand peaks before normal usage.
For this reason, the “general protocol for smart government” must set mandatory standards for scalability and resilience, not as a performance enhancement, but as a condition for accepting any connection or service. It must define, for example but not exclusively, how an entity behaves when broadcasting an event becomes impossible, how temporary accumulation is managed without losing the truth, and how the pathway is restarted without duplication or contradiction.
The “protocol programming environment” then turns these standards into prior tests that do not permit the publication of any service that has not proven its ability to withstand pressure. The smart state is not measured by the quality of its performance on ordinary days, but by its steadiness when the pulse is tested at the height of need.
Fragile Integration: When Connectivity Becomes a Network of Understandings, Not a Network of State
One of the ailments of today’s integration is that much of it is built on bilateral connections: one entity adapts to another, an interface is modified for a service, and an exception is tailored for a case. This pattern succeeds at first, then over time turns into a fragile network: any change in one of its nodes confuses other parties and makes maintaining integration more costly than building it.
The solution here is not “more coordination,” but a decisive return to what was established in the second part: integration must be managed by the “protocol,” not by meetings. The “general protocol for smart government” should impose: (1) a Canonical Request format. (2) A Canonical Response format. (3) National Error Semantics. (4) Binding Contracts managed through the Versioning Governance approach previously mentioned, so that entities are not broken by a sudden update.
The “protocol programming environment” then turns this into an integration marketplace: (1) the platform of published endpoints is not merely a “display guide,” but an “approval gateway” that permits only what complies with the national contract. (2) The platform of requested endpoints allows priorities to be built on real demand, not on the loudest voice. (3) The “automatic activation of connectivity” feature proposed in the second part becomes the rule; the state moves from exhausting paper-based integration to registered and binding digital integration. Only here does integration become a structure rather than a project, and expansion becomes a natural matter rather than a technical risk.
The Failure of the “Single Key”: When Identity Remains Identification, Not Operation
Having a digital identity does not mean that we possess a “government without forms.” The problem is not that the user cannot log in; rather, the user logs in and is then treated as a stranger: rewriting what the state already knows, proving what the state can prove, and uploading documents originally produced by the state itself. Here, the structural meaning we established earlier is completed: the move from the “image of the document” to the “data of the document,” and from “the citizen as intermediary” to “the state summoning its data from its sovereign source.”
The “general protocol” must set a strict operational rule: (1) no beneficiary should be asked for a document that the state possesses as structured data in any sovereign system. (2) Digital identity should not be used only for authentication, but to activate automated Attribute Retrieval according to data ownership governance.
The “programming environment” then translates this through: (1) defining “standard retrieval services” from sovereign entities, such as identity data, qualifications, employment status, and so on; and (2) requiring services in “Sahel” to declare the data they need through structured files, as previously proposed, such as JSON, so that it can be automatically fetched from trusted “endpoints.” Only then does the “single key” become a real key: it does not merely open the door; it operates the house.
The Expansion of the Cyber Fragility Surface: When Connectivity Expands Without a Sovereign Standard
However mature the structure and integration become, connectivity, if not guarded by one standard, becomes more dangerous than isolation. The digital state is attacked through its weakest link, not its most famous one. For this reason, the “general protocol for smart government” must include a security chapter, not as an ethical recommendation but as a technical requirement: (1) Zero Trust Integration as a national rule. (2) Mandatory standards for authentication, encryption, and certification, such as mTLS, certificates, and OAuth2 according to the nature of the connection. (3) Unified logging and monitoring as part of the “connection contract,” not as an additional option.
The platform of the “programming guide for inter-entity integration” within the “programming environment” then becomes the sole reference: (1) any entity that does not comply is not integrated. (2) Any “endpoint” that does not have a standard traceability log is not published. (3) Any connection that does not pass through a registered automated activation pathway is not nationally recognized. In this way, security transforms from institutional disparity into the sovereignty of a standard.
National Observability: When the State Sees Itself While It Works
Security is not complete, and trust does not stand, unless the state is able to see what is happening in its digital system with comprehensive real-time visibility. The problem is not only preventing breaches, but the absence of the ability to detect failure before it turns into a crisis. Here, the concept of “observability” appears not as a technical tool, but as a sovereign property of the smart state system.
The “general protocol for smart government” should impose—alongside logging and monitoring—a unified national model for tracing service journeys from beginning to end, so that every transaction, every event, and every data retrieval is connected to one context that can be traced chronologically and logically across entities. The source of failure should no longer be unknown, nor should the cause become lost between systems.
The “protocol programming environment” translates this principle into operational reality by requiring entities to send tracing data according to a unified standard and gather it in a national performance mirror that shows where the service slowed down, where it failed, and where retrieval was repeated without need. A state that cannot see itself while it works cannot repair itself while it breaks down.
The Absence of an “Operating Technical Mind”: When the Service Does Not Become a Decision Machine
Automation remains incomplete unless we move the state out of the logic of “completing the request” and into the logic of “operating the condition.” The smart state is not a faster interface; it is a state that knows when it should launch a procedure by itself. Here, the structural building reaches its technical purpose: the “protocol” does not only define the shape of data, but also defines operating pathways. It establishes: (1) a national definition of Service States. (2) A national definition of Triggers. (3) Rules for State Transitions. (4) So that an Orchestration layer can be built above them.
The “national platforms” then translate this into reality: (1) the service is listed not merely as a page, but as a journey with states, conditions, and pathways. (2) The “programming environment” becomes the place that ensures the service is automatable, not merely displayable. At that point, “Sahel” moves beyond the role of “window” and into the role of “journey orchestrator” within the limits of the structural constitution, not through a revolt against the structure.
Managing Complexity: When Automation Must Not Become a New Burden
Yet the transition to the logic of states and triggers, if not managed with technical wisdom, may lead to a dangerous paradox: automation itself may become a source of complexity greater than the one it was meant to solve. Every complex government service contains within it dozens of possible pathways, and with every uncontrolled exception and every uncodified condition, operating states multiply until the system becomes difficult to understand, maintain, and hold accountable.
Here, the role of the “general protocol for smart government” emerges not merely as a regulator of communication, but as a guardian of complexity. It must set upper limits on the branching of pathways and require entities to engineer their services according to Abstract State Models that prevent the inflation of internal logic and keep the service capable of automated operation and human understanding at the same time.
The “protocol programming environment” then translates this control through tools that force the developer—before publication—to describe pathways, limit exceptions, and connect every state transition to an explicit and traceable reason. Wise automation does not mean that we do everything automatically; it means that we know precisely when and why the system does what it does, without allowing its logic to multiply until it escapes control.
Technology Is Not Complete Unless It Is Governed
This dimension makes clear that the technical challenges in the “Sahel” experience are not scattered failures to be treated with localized improvements, but inevitable results of the absence of a governing framework that binds everyone to one logic and subjects flow, integration, security, and automation to a higher reference that is not fragmented by the fragmentation of entities. The state does not transform digitally because it has acquired newer tools, but because it has decided how these tools are managed, who has the right to define their rules, and who is held accountable when they deviate.
This article has shown that technology—however mature—cannot produce a smart state by itself. It can broadcast, connect, operate, and observe, but it cannot impose discipline, settle priorities, resolve conflicts between entities, or protect the “single truth” from multiplicity. All of these are not technical matters, but governance decisions at their foundation, settled not by programming but by public policy and binding standards.
If the “general protocol for smart government” was set out—in its structural part—as a digital constitution, and translated—in this technical part—into pulse, operation, and resilience, then the unavoidable question now is: who possesses authority over this constitution? Who enforces compliance with it? And who monitors its effects? A “protocol” without strict governance is no more than a moral agreement, and technology without accountability is no more than speed without direction.
From here, moving to the governance dimension is not a jump in the subject of the series, but a logical requirement of what came before. No state can operate by the logic of the event, integrate through a “protocol,” or automate its decisions unless the questions of data sovereignty, the performance mirror, centers of decision, limits of delegation, and mechanisms of national accountability are settled. The smart state is not managed by servers, but by the rules that govern those servers.
In the fourth part of this series, we will leave the space of “How do the systems work?” and enter a more precise and more dangerous space: how is the state governed when it operates digitally? How can governance be built so that it neither disables automation, empties the “protocol” of its meaning, nor reproduces centralization in the name of organization? That is the real test of digital transformation, and it is the link that, if sound, will make what comes before it and after it sound as well.
O Allah, ordain for this nation a matter of right guidance.