Digitising the Mukhtar: How to Modernise a 150-Year-Old Institution Without Replacing It

The default assumption of most government digitisation is that the human intermediary is the inefficiency. Find the clerk, the counter, the local official — and route around them. Put the form online, verify identity electronically, remove the person, and the queue disappears.

In Lebanon, applied to the Mukhtar, that assumption produces a platform nobody can legally use.

This is the design argument for the opposite approach, and it generalises well beyond one country. I own the company building it, and I will state its status plainly before making any argument at all, because the argument is not worth much if the status is soft.

The status, first

Cedar Connect is pre-launch. Zero Mukhtars are onboarded. No Ministry of Interior recognition is held — it is being pursued, not claimed. No partners are signed.

Working code for all three applications exists, built during a prior venture, and its IP ownership is being settled with counsel. Nothing about the platform is represented as owned until that closes.

What is not speculative: C.I.S. Services s.a.r.l. is a Lebanese company registered on the Beirut Commercial Register on 22 May 2012, active, owned outright with no partners and no shareholders. The launch catalogue is the 22 official Mukhtar administrative forms.

I would rather publish that paragraph than a number I cannot evidence. It also means the rest of this article is a design argument rather than a success story, and should be read as one.

What a Mukhtar actually is

A Mukhtar is a locally elected official who certifies identity, residency and family status. The institution is one of the oldest continuously functioning layers of Lebanese governance.

The critical property — the one that determines the entire design — is why a Mukhtar's certification carries weight. It is not that they hold a database. It is that they know the community personally. A Mukhtar certifying that you reside where you say you reside is not performing a lookup; they are staking a locally accountable reputation on personal knowledge.

No software layer can manufacture that. It is not a technical function being performed inefficiently by a human. It is a social function that has legal standing precisely because a human with local accountability performs it.

Any digitisation strategy that treats it as a lookup is not building a faster version of the institution. It is building a different institution, without the property that made the original one work.

The actual problem is access, not verification

If the verification layer is sound, what is broken?

Presence. You must be physically there, during hours that rarely match anyone's working life.

Distance. For millions of Lebanese living abroad, the ritual becomes a transcontinental relay: a cousin, a phone call, a favour, a scanned paper of uncertain validity, and a document that may or may not be accepted when it arrives.

Opacity. Once a request is with someone, its state is unknown until it is finished. The only status-check mechanism is to ask, which means the system's throughput is partly consumed by people asking about throughput.

Repetition. The same identity details are transcribed by hand onto a different official form, every time.

Notice that none of these is a verification problem. All four are access and workflow problems, and access and workflow problems are exactly what software is good at.

The design principle

Digitise access to the institution, not the institution.

The Mukhtar keeps the judgement, the local knowledge and the legal authority. Software removes the trip, the opacity and the transcription.

That principle produces a three-application architecture, which is what Cedar is.

Cedar Connect — the citizen application. Phone-number sign-in with a one-time code, because a password is a barrier for exactly the users who most need the service. A catalogue of the 22 official forms. Request, pay, track, receive. Finished documents land in an encrypted wallet the citizen controls, so the next request that needs them does not begin with a photocopy.

Mukhtar Portal — the operator's workspace. Requests arrive in real time. Identity details entered once populate every form that needs them. A two-mode print system handles both pre-printed official stationery and complete document output, because offices differ and a system that assumes one is a system half the offices cannot use. A permanent client registry, because the people a Mukhtar serves are a lasting relationship rather than a series of transactions.

Cedar Command — the internal console. Onboarding and tiers, service pricing, settlements and payouts, analytics and an audit log. The only surface with an administrative panel, and the only one behind mandatory two-factor authentication.

Three decisions that carry the design

The Mukhtar has no admin panel. This looks like a limitation and is the opposite. Pricing, service configuration and onboarding are governance functions, not operator functions. Putting them in the operator's tool guarantees inconsistency across offices, which is the failure mode that destroys trust in a national service. The operator gets a professional workspace; governance lives where it can be audited.

Enter once, print anywhere. The single most valuable thing the software does for a Mukhtar is eliminate re-transcription. It is not glamorous and it is where the daily hours actually go. Adoption of a professional tool is decided by whether it removes drudgery, not by whether it has features.

Phone OTP, no passwords. The citizen application's users include people who are elderly, abroad, on poor connections, and not confident with technology. Every password is a support burden and an abandonment point. A phone number is something every user already has and already trusts as an identity anchor.

The diaspora case, which is the commercial one

The strongest argument for building this is not domestic convenience. It is that a very large number of Lebanese live abroad and still need Lebanese paperwork — for inheritance, property, marriage, citizenship for children, and estates.

For that population the current process is not merely inconvenient; it is a genuine barrier, dependent on having a willing relative in the right place with the right time. It is the clearest case of demand that exists, is unserved, and is unserved for reasons that are entirely logistical.

It also imposes a design constraint that improves the product for everyone: build for someone in a different time zone, on a phone, on an unreliable connection, who cannot walk into an office to fix a problem. A system that works for that user works for the domestic user trivially. The reverse is not true.

Why a phone number is the right identity anchor

The identity decision deserves its own section, because it is the one that most reviewers question and the one I am most confident about.

Cedar Connect signs a citizen in with a one-time code to their phone. No password, and no attempt at electronic identity verification.

The objection is obvious: a phone number is a weak identity. That is correct, and it is also beside the point, because the application is not where identity is verified. Identity is verified by the Mukhtar, in person, using local knowledge — which is the entire premise of the institution and the reason its certification has standing.

Once you accept that, the application's identity job becomes much narrower and much more achievable: it needs to reliably associate a session with a person who will present themselves, and to keep somebody else out of that person's documents. A phone number does that adequately, and it does it for a population that includes people who are elderly, abroad, on poor connections, and not confident with technology.

A password does the same job worse, for that population. It adds a thing to forget, a reset flow that is itself an attack surface, and an abandonment point at exactly the moment of first use. Every password-reset email is a support ticket and a lost user.

A national electronic identity scheme would do the job better, and does not exist. Designing against one that might arrive is designing a product for a country other than the one that exists.

The general principle: put the identity strength where the legal weight is. If the human layer is doing the verification, the software layer does not need to duplicate it, and duplicating it costs you the users who most need the service.

Trust, and the six categories

The launch catalogue is the 22 official Mukhtar administrative forms, organised across six service categories. The catalogue structure carries a design commitment that is easy to miss.

Some categories require partners that are not signed — payment rails, couriers, and others. Those categories exist in the structure and are marked as requiring partners, and they stay that way until an agreement exists. They are not populated with plausible-looking placeholder logos, and the category is not quietly renamed to something that sounds live.

That is a small decision with a large consequence for a government-adjacent platform. A citizen who discovers that one listed service does not actually work will reasonably assume the others do not either. Trust in a service like this is not accumulated feature by feature; it is a single quantity that one broken promise removes.

The same principle governs what this platform says about itself publicly. Zero Mukhtars onboarded is on the record because it is true, and because a platform that overstates its adoption before launch has nothing left to say when it actually has some.

What has to be true before any of it matters

Four things, and none of them is code. This is the part most GovTech pitches skip.

Recognition. A digitised process that produces documents an institution will not accept has produced nothing. Ministry of Interior recognition is being pursued. It is not held. Until it is, the platform is a well-designed system without standing.

The operating model. Operate, licence, or hybrid — not yet decided. It has to be settled before the first Mukhtar is recruited, because whoever signs that Mukhtar owns the relationship, and getting the sequence wrong is not something a later decision can undo.

Payment and courier rails. A service that ends with a document has to physically deliver the document. Those partners are not signed, and until they are, the category stays unnamed rather than being filled with a plausible logo.

The IP settlement. With counsel, outcome unknown. It is the highest-priority open item and it gates everything public.

I list these because a GovTech platform's real risk is almost never technical. The code is the easy part; I have written it. The hard part is a set of institutional relationships that no amount of engineering substitutes for — and a pitch that presents the easy part as the whole is a pitch that will be found out.

What generalises

Four transferable lessons for anyone modernising an institution with a human verification layer.

Identify what the human is actually doing. If they are performing a lookup, automate it. If they are staking local accountability on personal knowledge, do not — you cannot, and the attempt produces a system with no legal standing.

Attack the access problem, which is usually the real one. Presence, distance, opacity and repetition are software problems. Judgement is not.

Give the human a tool, not a portal. The operator's software should remove their worst hour of the day. That is what determines adoption, and adoption is what determines whether any of it works.

Publish the honest status. A pre-launch platform described as pre-launch keeps its credibility when it launches. One described as further along than it is spends that credibility before it has earned anything.

Why this instead of something easier

Because the alternative — routing around the Mukhtar — has been tried in various forms in various countries and it produces the same result: a technically excellent system that the institutions it depends on do not accept, aimed at a population that keeps using the human process because the human process is the one that works.

The Mukhtar institution is not the obstacle. It is the asset. The obstacle is that reaching it requires being in a particular place at a particular time, and that is the only part worth removing.

---

What I bring that a GovTech vendor cannot: I own the Lebanese company, I specified and built all three applications, and I am publishing the open items that gate the launch rather than waiting for diligence to find them.

---

Carlos Kfoury owns C.I.S. Services s.a.r.l. outright and architected all three Cedar applications personally.

Related: The Mukhtar Goes Digital · Leading Through Collapse · Building a National Security Index