Click here to download the full series in PDF format.
In this part of the series, we continue what we began in the first reading, but here we dive deeper into the dimension that almost carries within it both the “cause of the system” and the seeds of its reform: the structural dimension. The challenges we referred to in the first part—the absence of a “unifying digital mind,” the fragmentation of national data engineering, and the dominance of the inherited paper-based model—were only initial signals pointing to more deeply rooted layers in the structure of the digital state. These are layers whose effect is not perceived by those who look only at the interface, but by those who listen to what happens behind the screens: deep within systems, between the folds of data, and inside service pathways that inherited from paper what digitization has not yet been able to overcome.
That is because “Sahel”—with all its virtues—was not built on clean ground. It landed on terrain fractured by differences: systems distant from one another in their logic, data speaking in discordant dialects, and services first designed with an administrative mind born in the age of paper, then dressed in digital clothing without being re-engineered from their roots. The application came ahead of its environment, extending bridges between islands that do not meet, gathering what had been scattered into a single interface; yet no matter how efficient it becomes, it cannot unify what the structures behind it have not agreed upon.
Because this part is devoted to reading the structural dimension with greater technical precision, we reopen those three challenges, but slowly and through a deeper lens. We place the “absence of the unifying digital mind” under a light that reveals the problem was not merely the absence of centralization, but the divergence of the rules by which entities connect to one another; and that the gap is not so much the absence of a mother system as it is the absence of a national language not yet written between systems. We examine the “fragmentation of national data engineering” not as a difference in storage models, but as an obstacle that undermines the possibility of building a government based on one stable, trusted piece of information, circulated among entities as though it were one page. Then we reconsider the “inherited paper-based model,” not merely as a technical obstacle, but as an administrative mindset embedded at the core of the service, reproducing itself whenever digitization attempts to dress it in new clothing.
The purpose of this part is to dismantle the structure through an approach that brings the idea closer without abandoning its depth: to reveal the points of failure where rules are planted, not where interfaces appear; to place possible solutions at the level of national engineering, not localized adjustment; and to show, as much as possible, how the state can move from a distributed system that agrees only under necessity, to a coordinated system that operates with decentralization in systems, but with centralization in protocols and standards—until integration becomes a binding choice, not an exhausting exception.
This chapter, then, is a chapter on “structure before service,” on “logic before interface,” and on the “digital language” that must be unified before the state can speak with one tongue. It is an indispensable prelude to the later parts that will address the other axes, because what is not sound in the structure will not be sound—no matter how hard we try—in technology, governance, or the automation we seek.
The Centrality of the Protocol; the Decentralization of Development
Perhaps the most suitable entry point to this dimension is a metaphor from the world of technology itself: a world that realized—long before governments—that absolute centralization is not the path to success, and that the greatest systems did not rise through the weight of their internal developers, but through the environment that allowed others to innovate on top of them. If we reflect on the beginnings of major operating systems—from Windows to macOS—we find that their first crisis was not the ability of their companies to program, but a deeper question: can an operating system rise if it is not opened to others to build upon it?
Imagine, even for a moment, a Windows system closed in on itself, running only what Microsoft designed internally: no external programs, no diverse applications, no tools beyond the company’s imagination at the first launch. What would such a system have looked like? Limited in services, narrow in horizon, repeating itself by itself, and unable to keep up with needs that no company—however large—could count, predict, or serve alone. Such a system would never have become a backbone for millions of users, nor a platform on which thousands of applications were built, creating its real value.
The decisive transformation came when those companies realized that success does not rest on monopolizing programming, but on building an environment that allows the whole world to program on top of it; an environment governed by clear protocols, organized by common standards, and guaranteeing that whoever complies with them can list their application on the platform and reach users immediately. Only then did the number of applications multiply, system capabilities expand, and millions of segments—never imagined by the companies themselves—find their needs met through applications built by developers with no connection to the parent company. In this way, the value of the system came to lie in what is built upon it, not only in what its own developers build.
Then came the smartphone revolution, which did not reinvent the wheel. Apple and Google repeated the same approach: decentralization of development, centralization of protocol. Thousands of applications flowed into official stores, and the developer environment became the core of the system’s success, until users came to choose their phone not only for the strength of its hardware, but for the richness of the platform and the strength of the environment fed by countless applications.
Across all these examples, the larger lesson appears clearly: the optimal investment was not in increasing the number of developers inside the company, but in engineering an open environment that operates according to defined protocols and allows anyone—so long as they comply with the standards—to connect their data, ideas, and tools to the mother system. Value is not created through centralization, but by opening the field under a unified ceiling of rules, where freedom exists in building, language is unified in communication, and innovation intensifies not by disciplining developers inside the company, but by the rush of minds around the world to build on top of the system.
Government Entity Developers Know Their Own Terrain Best
If we move beyond the technical example to the reality of Kuwait, the image is not far removed. The companies behind operating systems—with their developers, engineers, and protocol designers—are a close analogy for the entity supervising the “Sahel” application. And the developers outside those companies, who create thousands of applications in open environments, are another analogy for the technical teams working in ministries and public authorities, each within its own domain, service, and responsibility.
Yet what is happening today in Kuwait almost reverses the model that technology companies recognized as deeply mistaken decades ago. Before any new service is added to “Sahel,” programming teams become involved in joint and intensive work between the platform’s developers and the developers of the government entity: continuous discussions, reciprocal modifications, and details that sometimes reach the level of service engineering itself, the form of data, and the method of storage. This approach, though it may appear on the surface to be commendable cooperation, is in essence a sign of centralization that remains embedded despite all appearances of digitization; a centralization that makes the addition of a single service a difficult project, slows innovation, narrows the horizon of development, and pushes—consciously or unconsciously—toward avoiding the more complex services because they require shared modifications beyond the capacity of the platform, the entity, or time.
Not only that: when every new service becomes hostage to direct cooperation between the central team and the entity’s team, the digital system becomes something like a closed operating system. Nothing works in it unless it is designed under the supervision of the central entity or in step-by-step coordination with it. By the standards of digital engineering, this is not evidence of the system’s strength, but of a limitation that constrains it: a limitation in speed of response, in the breadth of service coverage, and in the system’s ability to grow organically—the kind of growth that usually comes from the entities themselves before it comes from the center.
All of this raises a structural question that cannot be ignored: what if we moved from the centralization of programming to the centralization of protocol? What if we left each entity free to engineer its data and service logic, so long as this does not affect its ability to integrate into the national system through one protocol? What if the state did not ask the entity how it stores, how it engineers, or how it manages its internal logic, but only asked how it “presents” its service according to a national language that does not change?
Each entity—whether ministry or authority—knows itself best, is closest to the details of its services, and is most capable of innovating what suits its users. Digital integration should not come at the expense of this specificity. National harmony does not mean erasing differences, but regulating them under one ceiling. Therefore, integration should not exceed the level of the communication protocol through which entities speak to “Sahel” and to other “unified national platforms.” What lies beyond that—data logic, form structures, methods of storage—should remain the right of the entity, not the right of the “national platform.”
The purpose of the protocol is not for the central entity to participate in programming, but to set a binding technical standard through which service quality is verified, and for what the government entity produces to be listed in “Sahel” only if its compliance with the protocol is complete. If the central entity needs to participate in programming or rewrite the logic of the service, then—by the logic of engineering—this is not a sign of service complexity, but a sign of weakness in the protocol, which should have allowed the entity to complete its work fully without intervention, just as developers around the world program their applications without participating with operating system developers in writing their internal software.
Thus, the rule on which the entire structural solution rests becomes clear: the more programming is shared, the less mature the protocol is; and the more mature the protocol becomes, the less entities need shared programming.
The “General Protocol for Smart Government”: The Constitution of Automation
For the structural building we seek to stand upright, there must be a framework that organizes the relationship among all parties in the system: a framework resembling a “digital constitution” at which languages unite, methods of communication become ordered, and mechanisms of inter-entity connectivity become subject to it without touching the specificity of each entity, interfering in its internal logic, or turning digitization into suffocating centralization. This framework is what we call here the “general protocol for smart government.”
This protocol is not interference in the content of data or the way it is stored. Rather, it is a governing standard that defines how the state communicates digitally, how its entities connect with one another, and how natural and legal persons benefit from the services provided by those entities, according to unified rules that ensure consistency, open the doors of innovation, and preserve the state’s sovereignty over its data.
The protocol rests on three parties whose roles complement one another without one overwhelming another:
First: Government Entities — Service Providers
They are the first party in the system and include all ministries, authorities, and public institutions, each according to its jurisdiction. These entities: (1) retain full independence in the engineering of their data, (2) in the logic of their services, (3) in their methods of storage and operation, and (4) in their innovation of what suits their users, so long as all of this takes place behind the interface and does not conflict with compliance with the protocol when presenting those services through the “unified national platforms” for government services.
The standard here is not the unification of systems, but the unification of the language of communication between systems. What is required is not to change the logic of ministries, but to make that logic presentable and usable through shared rules. Therefore, in this structural model, the government entity resembles application developers in the digital world: it works according to what it sees as suitable for its users, but when it deals with the “unified national platforms,” it complies with the language of the protocol, not the language of its internal systems.
According to this conception, the Public Authority for Civil Information, for example, becomes part of this party because it is a service provider—data and authentication—and its compliance with the protocol is not an exception or privilege, but a general rule applying to every government entity, regardless of its weight or the sensitivity of its data.
Second: Citizens and Residents — Beneficiaries of Services
They are the first and final purpose of this system: individuals, companies, and institutions; citizens and residents; natural and legal persons who benefit from the services provided by entities through the “unified national platforms.” In these platforms, the differences between one entity and another should not appear to them, nor should they be burdened with tracking or understanding those differences.
The “general protocol for smart government” guarantees for them: (1) a consistent digital experience, (2) unified data at the output level, (3) services built on an environment free from duplication, and (4) a pathway that does not burden them with the complexities of entities’ internal systems.
Third: The Entity Supervising the “Protocol”
This is an independent government entity that is not assigned a service jurisdiction and is not entrusted with executive tasks outside the scope of the state’s digital engineering. Its purpose is to be the governing reference for the national connectivity system, the guarantor of the consistency of the state’s digital language, and the supervisor of the structure through which entities communicate with one another and with beneficiaries. Its role rests on three main axes:
(1) Formulating the “General Protocol for Smart Government”
As the digital constitution of the state and the supreme reference that does not merely unify the form of data exchange, connectivity standards, authentication, message codes, and response methods, but goes beyond that to engineer the digital relationships between the entities themselves. It redefines each entity’s responsibilities toward others, not as neighboring bodies in an administrative apparatus, but as digital nodes in one system whose functions complement rather than repeat one another.
In this sense, the protocol does not only define how entities communicate, but what each entity must provide digitally to other entities. For example, and without limitation, the Public Authority for Civil Information becomes—as it is today, and according to the logic of the protocol—the national entity digitally responsible for providing authentication and identity verification services to all government entities, as the first gateway of trust for every digital service, and for supplying other entities, when needed, with the basic data associated with the civil number whenever that is necessary to complete a specific service, without requiring the beneficiary’s authentication each time if the nature of the service permits this from a governance standpoint.
The same applies to the Ministry of Higher Education, which—within the logic of digital responsibility—is tasked with providing government entities with data on the beneficiary’s equivalenced academic qualifications, whether this occurs through beneficiary authentication or through direct inter-entity connectivity where the nature of the service requires it. Thus, data is no longer “silent property” confined inside an entity’s systems; under the protocol, it becomes a national digital function performed for others just as it is performed for the beneficiary.
From here, it is necessary to distinguish precisely between the protocol as a general governance system and the programming guide as an execution tool. The protocol does not replace the developer guide and does not descend to the level of code. Rather, it sets the sovereign framework under which the technical guides are built in the “protocol programming environment.” It is closer to a digital constitution from which technical rules are derived, not a manual of instructions for developers.
The protocol also ensures that services provided through the “unified national platforms” for government services are built on the engineering of “services without documents”; that is, beneficiaries should not be asked to submit a document that the state already possesses in its databases. It is not logical for smart government to ask a beneficiary, for example, for a certificate from the Public Institution for Social Security, while the entity providing the service can—through direct connectivity via the “protocol programming environment”—pull the necessary data automatically, instantly, and only to the extent needed, without burdening the beneficiary with moving between entities. This approach necessarily requires establishing “data ownership governance” as a sovereign pillar, not merely a technical one. It is not enough for data to be available; it must be settled: who owns the “original truth” of the data? Who is authorized to view it? Who is licensed to invoke it? Who is prohibited from modifying it? Only in this way can duplication of sources be broken, conflicts of truth prevented, and unity of reference preserved, so that entities do not dispute data, nor are its versions repeated in more than one place. Instead, every piece of information retains its digital sovereign authority from which it is invoked and not copied.
Another equally important direction branches from this: the move from the logic of the “image of the document” to the logic of the “data of the document.” Service providers should be directed to provide structured, detailed data for every document, rather than merely uploading a static scanned copy of it. In smart government, a document is not an image to be stored, but data to be read, analyzed, connected, and invested in automation and decision-making.
At the governance level, this protocol is not regarded as a closed document or a rigid system, but as a living entity subject to continuous updating in its policies, rules, and standards, keeping pace with the evolving needs of the state, the maturity stages of smart government, changing cybersecurity requirements, improvement of service performance, enhancement of proactivity, and achievement of comprehensive automation. It is a system that develops with the state, does not lag behind it, and does not blindly run ahead of it. This continuous updating requires the protocol itself to be managed through Versioning Governance, not through sudden replacement. One version should not be replaced with another in a way that confuses the system, nor should an existing connection be broken by an urgent update. Versions should instead be managed through gradual patterns that preserve backward compatibility, define a binding operating life for each version before retirement, and, by way of example, assign each “endpoint” its version number, so that the transition between stages of the protocol remains safe and free from shock, a firm advance without interruption. The smart state does not update its digital mind by leaps, but through disciplined accumulation.
Thus, the protocol is no longer merely a technical language for exchanging messages, but a national engineering of digital relationships, defining who provides, who consumes, who authenticates, who feeds data, and how this entire cycle is managed under one ceiling of consistency and sovereignty.
(2) Managing the “Unified National Platforms”
Such as the “Sahel” application and other “unified national platforms” that shorten beneficiaries’ access to state services and display what entities provide in a unified pattern that does not conflict with each entity’s independence in engineering its data or developing its systems. In a sound structural conception, however, these platforms should not be rigid platforms managed with the mentality of slow centralized publishing. They should be reformulated as national marketplaces for government services, similar to official application stores in the world of smartphones.
Just as Google Play and the App Store do not create applications, but host them, organize them, and display them, the “unified national platforms” should not be expected to engineer services or program them. Rather, they should be the national operating system for services, onto which the services created by government entities are listed according to the rules and standards set by the “general protocol for smart government” and the “programming environment” derived from it, without any direct intervention in building the service by the entity supervising the platform.
The role of the supervising entity here is governance and review, not programming and implementation. It evaluates listed services technically and from a governance standpoint, then either approves their listing and publication to beneficiaries, or rejects them with reasons, on the basis of which the service is improved, its models adjusted, or protocol requirements completed. In this way, the platform moves from the role of “executor” to the role of “regulator,” and from the role of “producer” to the role of “judge”—a fundamental transformation in the philosophy of the digital state. This governance becomes complete when the unified national platforms are connected to a system of “real-time service performance governance,” so that no service is published and no journey is managed except under mandatory indicators measured instantly: response time, availability rate, failure rates, and satisfaction levels. Services are then seen not through impression, but through numbers; entities are held accountable not through complaint, but through data; and the state is managed not through assumption, but through real-time observation of its performance as it is, not as it is narrated.
Government entities, in this model, have full control over the form of the service, its forms, its operating mechanism, its steps, its stages, and the flow of its procedures—all within an advanced “programming environment” that enables their technical teams to innovate without suffocating central restrictions, so long as compliance with the protocol exists at the point of display and connectivity.
These “unified national platforms” are developed from the outset to accept all forms of services, with their varying levels of complexity, their different specificities, and their diverse pathways, so that adding—or updating—a new service becomes similar to adding a new application to an official store. The entity submits the basic service data, then its descriptive details, then its usage guides, then the files of its operational models—perhaps in structured formats such as JSON—including beneficiary data fields and the data required from other government entities. It then submits the files of the service steps and pathways, however branched and complex they may be. The “protocol programming environment” is the precise technical reference that explains how these files are built, how they are delivered, how their integrity is tested, and what approval standards apply before publication.
At that point, the beneficiary—by simply downloading the national platform application—does not receive a copy of services, but enters a living system that expands over time. Services are added gradually, functions expand, steps are shortened, and the data needed to complete services is gathered by the shortest paths. Every service in this system is the outcome of time, work, and decentralized technical expertise invested to provide the beneficiary with all necessary data, options, and steps in a way that the centralized model, by its nature, cannot achieve.
In this way, the golden rule of the digital state is restored: government entities create their services; the “national platforms” host, display, and organize them; and the supervising entity governs the language and standard, not the logic and implementation. In this way as well, government entities become the direct and actual controllers of the services they provide through the “unified national platforms,” without the state losing its digital unity, its service discourse fragmenting, or the user experience becoming disturbed.
(3) Managing the “Protocol Programming Environment”
This is the environment in which the supervising entity establishes programming rules, formulates guides, and updates standards, so that it becomes the supreme technical intermediary enabling government entities to connect their services to the “unified national platforms” and to one another, in compliance with a fixed protocol that does not change. This connectivity does not require shared programming, interference in the internal engineering of entities’ systems, or rewriting the logic of their data. It is not based on a shared database or a unified development platform, but on a regulating framework that ensures the unification of the language of communication between entities, regardless of how different their internal pathways, technologies, or operating methods may be.
Yet this “programming environment,” in the deeper structural conception, is not a static platform updated at long intervals, but a living national marketplace for programming guides, performing in the world of connectivity and integration the same role that applications perform in the “unified national platforms” for government services. It is not a marketplace for services, but a unified marketplace for programming guides that define how services are built, how they are connected, and how entities communicate digitally.
This environment is divided into four integrated sub-platforms, which together form the executive backbone of the “general protocol for smart government”:
Platform One: The Guide for Managing and Programming Services in the “Unified National Platforms”
This guide is managed directly by the development team of the entity supervising the “general protocol for smart government,” and is accessible to developers in all government entities. It is the supreme reference for engineering national services, presenting: mechanisms for managing the services provided by entities through the “unified national platforms,” how to add them for the first time, mechanisms for updating and developing them, the form of files required to represent service models, the foundations and standards governing their management stages, the criteria for approving their listing, and the reasons for exclusion in cases of non-compliance with requirements.
In the precise technical sense, it is a user guide for an integrated programming structure of the state. It does not teach the developer how to write code, but how to place their service in the correct national context, so that it is displayed, operated, and managed within the “unified national platform” without violating standards.
Platform Two: The Programming Guide for Connectivity Between Government Entities
This guide is also managed directly by the development team of the entity supervising the “general protocol for smart government,” and is accessible to developers in all government entities. It is concerned with formulating the governing conditions of the technical relationship between entities. It defines: authentication mechanisms during connectivity, such as requiring mTLS certificates, using SSL/TLS, complying with the OAuth2 protocol, along with IP Whitelisting controls; the form of the Request input so that it is fixed between entities; the form of the Response so that it is unified in JSON format; and the form of response failure, Error Handling, with fixed semantics, Status Codes / Error Objects, to which all entities must adhere without exception. This connectivity does not stop at the level of tools, but is philosophically built on the principle of “Zero Trust Government Integration,” where trust is not granted to any entity by default, and no request is authorized automatically. Rather, every exchange is reverified each time, every response is recorded, and every behavior is analyzed. In this way, the state moves from security based on “good assumption” to security based on “constant verification,” so that the system is protected not by its walls, but by its real-time awareness of everything taking place across its digital pathways.
This guide ensures that every government entity, regardless of its system, speaks one national technical language when connecting, so meanings are not lost between entities, interpretations do not multiply, and the data journey is not distorted as it moves.
Platform Three: The “Endpoints” Guide for Government Entities’ APIs
This guide is managed directly by the developers of government entities themselves, while allowing developers of other entities to view it. Through it, each entity displays its own “Endpoints” and the details of each endpoint: its requirements, request format, response format, access permissions, and required authentication data. The guide thus becomes a living national map of government connectivity points, enabling developers of other entities to connect directly and benefit from what any entity provides in order to complete services for beneficiaries, whether directly through the “unified national platforms” or through automated inter-entity operations.
As with listing services in the “unified national platforms,” listing any new “endpoint” in this guide passes through a stage of review and approval by the developers of the entity supervising the “general protocol for smart government.” It is approved and published once it satisfies the conditions, or rejected with reasons requiring correction and improvement.
Added to this platform—as its major operational leap—is the feature of automatic activation of connectivity between entities. The guide no longer merely displays “endpoints,” but becomes an official gateway for operating integration between entities. When a government entity wishes to connect with another entity that provides a specific “endpoint,” it submits—within the same platform—a request to activate the connectivity automatically.
At that point, the authentication data required between the two entities is exchanged automatically and securely, including digital certificates for authentication and encryption, Certificates / mTLS; Client Secrets; authorized IP addresses, IP Whitelisting; and all other identification data required for secure operation. The connection is then technically activated once requirements are completed, and this activation is recorded as an official approval between the two entities within the national system. In this way, automatic activation of connectivity replaces exchanged official letters, chains of bureaucratic correspondence, repeated liaison officer communication, and lengthy coordination meetings between technical teams.
Integration between entities is transformed from a heavy “administrative path” into a direct, registered, binding, and fully automated “digital path,” managed from one point and under one ceiling of governance, security, and authentication.
Platform Four: The Guide for “Endpoints” Requested Between Government Entities
This guide is also managed by the developers of government entities and is accessible to developers of all entities. Through it, entities display their programming needs from other entities. For example, when the Civil Service Commission provides a job application service and requires, in order to verify an applicant’s eligibility, confirmation that the applicant is not registered with Social Security, the developers of the Civil Service Commission request—through this guide—a programming “endpoint” from the Public Institution for Social Security to provide this data. Here, other entities vote on the actual need for this endpoint, so the most requested “endpoints” rise to the top of the priority schedule. The data-providing entity—such as Social Security—then programs the highest-priority “endpoints” first. Once the government entity programs a new “endpoint” and adds it to the API endpoints guide for entities, the system automatically alerts all entities that requested that “endpoint” that the service is now available for immediate use and connection.
Thus, integration between entities moves from paper correspondence, individual calls, and exhausting coordination meetings to a smart national marketplace where needs are managed, priorities are defined, and solutions are built according to real demand.
With this four-layered structure, the “protocol programming environment” is transformed from a mere document repository into a living engine of government innovation, institutional integration, and comprehensive national automation. Services are created, entities are connected, and needs are met without the system touching the foundation of decentralization in programming and development, nor the unity of the state in language and standard.
From here, it is useful to separate—conceptually before technically—between the “logic of the state” and the “logic of the interface.” Platforms are not the mind of the state, but its face; they are not the place of sovereignty, but the place of presentation. The true mind of the state lies in the protocol that organizes, the programming environment that activates, data governance that unifies, connectivity controls that protect, and automated decision engines that operate. If this mind is sound, the interface will be sound however varied it may be; and if it is impaired, the most beautiful applications will not compensate for its defect.
Through these integrated roles, the “general protocol for smart government” is no longer merely an organizational framework. It becomes the most fitting structural solution for dismantling the most complex dilemmas that have faced the “Sahel” experience since its emergence. On one hand, it treats the absence of the “unifying digital mind” not by imposing suffocating centralization, but by creating a unified national language under which systems integrate while remaining decentralized. On another hand, it puts an end to the fragmentation of “national data engineering” by establishing one digital dictionary, where meanings become ordered before code becomes ordered. Third, it uproots the “inherited paper-based model” from the heart of the service by turning the document into data, the manual pathway into direct data retrieval, and physical attendance into a digital signature that does not burden its owner.
Thus, the protocol does not treat symptoms of failure, but reaches its first cause: the place where relationships between entities are formulated, digital responsibilities are defined, and the language by which the state speaks to itself is built before it speaks to its beneficiaries. It transforms from a mere connectivity tool into a sovereign structure governing the entire path of digital transformation.
From here, this protocol does not represent only the conclusion of treating the structural dimension; it is also the cornerstone on which the ways of confronting the remaining challenges addressed by this series in its coming parts will be built—technical, governance-related, usability-related, and conceptual—part by part, week by week. There can be no sound technology without structure, no governance without a unified language, and no automation without a protocol that governs its pathways from the roots.
In this way, the structural dimension becomes the ground in which the stakes of the smart state are fixed before the layers above it are built.
O Allah, ordain for this nation a matter of right guidance.