I.

The core observation is that governance is composition. A board resolution is a sequence of steps: notice, convene, verify quorum, vote, record minutes, file. A shareholder vote adds steps: determine record date, distribute proxies, collect votes, tabulate, certify. A merger adds steps from both sides: each entity’s board must approve, each entity’s shareholders must approve, regulators must approve, and the approvals must compose into a single authorization.

This is sequential and parallel composition of approval steps. The board resolution is sequential: each step completes before the next begins. The merger is parallel: two independent governance processes run concurrently, and the merger proceeds only when both complete. Some operations mix the two: the board authorizes the merger sequentially, then the shareholder vote runs in parallel with the other entity’s governance process.

Process calculi (Hoare 1985; Milner 1989) supply the vocabulary. Writing ; for sequencing and ∥ for parallel composition that joins on completion, a board resolution is

notice ; convene ; quorum ; vote ; minutes ; file

and a merger of A and B is

((board_A ; shareholders_A) ∥ (board_B ; shareholders_B)) ; regulatory ; close

The fragment governance needs is small: sequencing, parallel join, and branches guarded by conditions already determined when the branch is reached (if the target is regulated, insert the clearance step). No communication between branches, no recursion, and none of the nondeterministic choice that gives full process calculi their difficulty.

We take as a design hypothesis that the governance requirements of the corporate actions considered here decompose into finitely many approval steps combined by these three operators. Two jurisdictions support it below; it is not established in general. In Florida, share issuance is a board program: the board holds the power (Fla. Stat. §607.0621), a quorum is by default a majority of the number of directors prescribed in the articles or bylaws, and the act of the board is a majority of the directors present (§607.0824). The Cayman Islands Companies Act fixes no issuance program at all: allotment is governed by the articles, and the Act’s model articles (Schedule 1, Table A), which apply by default to a company limited by shares (s.22(2)), leave it inside the directors’ general management power (reg. 66), subject to a pro-rata first offer to the members of shares created by an increase of capital (reg. 34). What the Act does fix is the program for changing the articles themselves – a special resolution (s.24), passed by a majority of at least two-thirds of the members who, being entitled to do so, vote on it, at a general meeting whose notice announced the intention to propose a special resolution (s.60(1)). The Act fixes no day count for that notice. Notice is duly given whenever it is given in the manner the company’s regulations prescribe (s.60(3)); where the articles are silent, the model articles are those regulations and require at least seven days (reg. 41); the Act’s own five-day figure is the backstop for a company with no regulation on summoning meetings at all (s.61). Different programs in different places – one living in a statute’s defaults, the other in the entity’s own constitutional documents, with the statute’s model articles and then its bare backstop layered beneath them – with one shape: a set of authority requirements, a composition of approval steps, and procedural constraints (quorum, threshold, notice) over named bases.

II.

The first design decision separates the governance rules from the governance engine. The rules are data: a typed, content-addressed artifact that declares what governance an action requires. The engine is the runtime that executes the governance steps: it creates the consent artifact – the signed record of an approval, whether board resolution, written consent, or shareholder vote – collects the votes, checks the quorum, and reports the result.

Concretely, a governance specification is a triple: a set of declared authorities, a mapping from corporate actions to the approvals each requires, and procedural parameters for each approval – quorum basis and fraction, threshold basis and fraction, notice period. Loading a specification checks its internal consistency: every reference resolves, every action maps to at least one declared authority, every quorum and threshold names a declared basis. The serialization is canonical, so equal specifications have equal hashes.

The separation matters because the rules must be auditable by lawyers, and lawyers do not read execution engines. A governance rule embedded in procedural code is opaque to the people who must verify that it matches the legal requirements. A declarative rule – authority: board of directors; quorum: majority of the prescribed number of seats; threshold: majority of directors present; notice: two days for special meetings – is something a lawyer can read, compare against the statute and the bylaws, and sign off on.

Content addressing is the second design decision. Every specification is serialized to canonical form and hashed, and the hash is the specification’s identity. If any field changes – an authority added, a threshold moved, a notice requirement removed – the identity changes. When an action references a governance specification, it references a specific immutable artifact; an amendment produces a new hash and a new artifact while old references keep pointing at the old rules. The reference is only as strong as its placement: the specification hash travels inside the signed content of the consent artifact, so substituting different rules after the fact breaks signatures, not just citations.

This property is what audit needs. When a regulator asks under what governance rules a share issuance was authorized, the answer is a content digest that resolves to one specific, immutable specification, compared against the governing documents in force at the time: these bylaws, as they existed on this date, producing this specification with this hash.

III.

A corporation is a hierarchy of authorities with different powers, different compositions, and different procedural requirements.

The board of directors is a collective body. It decides by voting, subject to quorum and threshold requirements. An officer, such as the president or secretary, is a single authority who can make certain decisions unilaterally within delegated scope. A registered service provider is an external participant with specific filing authority. In multi-entity structures, including corporate groups and joint ventures, authorities of one entity may hold delegated power over actions of another.

These are the nodes in the authority graph. The edges are delegations: directed relationships from one authority to another, scoped to specific matters and step types. A board can delegate signing authority to the president for routine filings. A parent company’s board can delegate certain approval rights to a subsidiary’s board for specific action types. Each delegation carries its scope explicitly: which matters it covers, which step types it applies to, and – for cross-entity delegations – what relationship between the entities justifies it.

The graph structure makes delegation chains visible and checkable. When a delegated program acts on behalf of an officer who acts on behalf of the board, the authority chain is traceable: the program’s action references the officer’s delegation, which references the board’s grant. Each link is a typed edge in the authority graph, and edges pass the same load-time resolution checks as everything else in the specification: an edge whose endpoints do not resolve is rejected.

IV.

The quorum problem is where machine-speed governance first demands precision.

A quorum is a count over a named eligibility basis, and the bases differ more than the fractions do. Florida’s default board quorum is a majority of the number of directors prescribed in the articles or bylaws (Fla. Stat. §607.0824(1)): vacant seats stay in the denominator. A seven-seat board with two vacancies and three directors present has a majority of its filled seats and no quorum – four of seven are required. Approval runs on a different basis again: the act of the board is a majority of the directors present (§607.0824(3)), not of votes cast, so with five present and two abstaining, a two-to-one vote in favor fails. A Cayman special resolution runs on a third basis – a majority of at least two-thirds of the members who, being entitled to do so, vote (s.60) – under which abstentions and absences drop out. Delaware measures charter amendments against a fourth: a majority of the outstanding stock entitled to vote (8 Del. C. §242(b)(1)), under which absence counts against. Four rules, four bases: prescribed seats, directors present, votes cast, shares outstanding. A specification that does not name its basis is not a specification.

For human governance at human speed, the quorum is verified by a secretary taking attendance. For machine governance at machine speed, the verification must be evidence, not observation. When a delegated program collects board votes electronically, showing that a quorum was reached takes more than a count: it takes a checkable record that the counted votes came from parties who were eligible at the moment of the vote.

Each vote is therefore an attestation: a signed statement by an eligible party naming the matter, the vote, and the specification hash. Verifying quorum and threshold means verifying the set: each signature valid, each signer on the eligibility snapshot, no signer counted twice, each attestation inside the governance window (after notice, before deadline) – then evaluating the threshold predicate over the verified set. The attestations remain individually accountable, because minutes must record who voted and how; an aggregation that hides the signers is disqualified.

The voting threshold is one more parameter over the same evidence. A simple majority, a two-thirds or three-quarters supermajority, and unanimous consent each define a different predicate on the aggregated attestations, over a basis the specification names.

Four trust roots stand under this verification, and they should be named. First, eligibility: the verifier needs a signed, time-stamped snapshot of the eligibility roster – the register of directors or members as of the record date – from whoever keeps the register. The record shows the votes came from parties on the snapshot; it cannot show the snapshot was true. Second, identity: a signature proves possession of a key, and binding the key to a person is the work of an identity layer; key compromise survives as a residual risk that no quorum arithmetic removes. Third, time: window checks are only as good as the clock, so attestations carry signed timestamps from a source the verifier trusts. Fourth, reference: the specification hash must sit inside the signed content of each attestation and consent artifact – a hash cited outside a signature detects nothing. What is mechanically checkable is exactly this: that the attestations satisfy the specification relative to the snapshot, the key bindings, and the clock. Whether the snapshot is honest and whether the specification matches the governing documents are the registrar’s and the lawyers’ obligations, not theorems.

When governance runs at machine speed, with vote collection and verification in seconds rather than days, the procedural safeguards encoded in notice periods and quorum requirements matter more, not less. The notice period exists so that eligible participants have time to consider the matter. If tooling can convene a “board meeting,” collect electronic votes, and report a quorum in seconds, the notice period is the check that protects the humans who are supposed to govern. The protocol must enforce the timing constraints precisely because the participants could technically act faster.

V.

A merger requires both entities to approve. Each has its own governance rules, its own authority graph, its own quorum and threshold requirements. The merger proceeds only when both have independently satisfied their own requirements. This is parallel composition: two governance processes running independently, with a join barrier.

Mergers are the simple case. A joint venture may need approvals from three entities, of different types for each. An agreement between two jurisdictions to recognize each other’s regulated activity needs approvals from authorities on both sides, under procedures that share nothing but the join. A regulatory approval may interleave with the corporate one: the board approves subject to regulatory clearance, and the regulatory application requires evidence of board approval. Even this stays inside the fragment: the board’s condition becomes a guard on the closing step, evaluated once the regulator has answered, and the regulator’s evidence requirement becomes a sequential boundary, the application running after the vote – board ; regulatory ; close with the guard on close, the shape the merger expression already has, and no communication between branches.

Two different joins meet in such operations. The governance join is a conjunction: each entity must satisfy its own approval predicate under its own rules, and no entity’s approval substitutes for another’s. The compliance join is a meet over verdicts: each participant’s compliance – sanctions above all – is evaluated separately, verdicts are ordered NonCompliant < Pending < Compliant, and the joint verdict is the strictest. One participant’s clean record does not lift another’s failure, because the prohibitions behind these checks attach to each party separately; the companion paper How Compliance Composes develops this composition and its legal grounding. Both joins are non-compensating, and both are declared in the specification – which participants, which join – rather than inferred at runtime.

VI.

Jurisdictional variation is the test of whether governance-as-code works. If encoding a new jurisdiction requires changing the engine, the abstraction has failed.

The engine holds no governance rules. It selects the specification by the jurisdiction and entity form of the target entity, reads what approvals the action requires, runs each approval – creates the consent artifact, collects the attestations, checks quorum, threshold, and window – and composes the results by the declared join. Every consent artifact it produces carries the identifier of the operation that requested it and the hash of the specification under which it was collected.

Consider a Florida for-profit corporation issuing shares and a Cayman exempted company limited by shares amending its articles. In Florida the board is the authority (Fla. Stat. §607.0621, reservable to the shareholders by the articles); the default quorum is a majority of the prescribed number of directors (§607.0824(1)); approval is a majority of directors present (§607.0824(3)); a special meeting takes two days’ notice of date, time, and place, and a regular meeting takes none by default (§607.0822). In Cayman the members are the authority, in general meeting; the threshold is a majority of at least two-thirds of those who vote (s.60(1)); the notice announces the intention to propose a special resolution (s.60(1)) and runs for the period the company’s regulations prescribe (s.60(3)) – at least seven days under the model articles that apply where its own are silent (s.22(2); Table A, reg. 41), five days only for a company with no regulation on summoning meetings (s.61). These are different specifications. The authorities differ (board vs. members). The bases differ (prescribed seats and directors present vs. votes cast). The thresholds differ (simple majority vs. two-thirds). The clocks differ (two days, scoped to special meetings, vs. seven days under the model articles, with the statute’s five-day backstop beneath them). The structure is identical: authorities with defined powers, procedural parameters over named bases, and a mapping from corporate actions to required approvals.

So adding the Cayman Islands changes no code. It adds a specification declaring the Cayman authority structure, procedural parameters, and reserved matters; the specification passes the same load-time checks as any other, is content-addressed like any other, and is discovered by jurisdiction and entity form like any other. The system’s jurisdictional coverage grows by adding data, not code.

VII.

Corporate governance has always been a protocol. Formalization was unnecessary while every participant was human and throughput was low enough for manual verification.

Two things are changing at once. First, delegated programs are becoming participants – executors, preparers, monitors. When the participant that distributes notices, collects votes, and files results is a machine, the protocol must be machine-readable. Ambiguity that a human secretary resolves with judgment becomes a failure mode for an automated system.

Second, the number of governance decisions is increasing. An entity that previously made a dozen governance decisions a year may make hundreds as share issuance, director changes, and routine filings move onto automated rails gated by governance checks. Hundreds a year is a governance action every working day. Verification at that rate cannot route each decision through a lawyer; it must be as automated as the execution.

None of the ingredients is new on its own. On-chain governance frameworks have executed quorum, threshold, and timelock logic for years (Kiayias and Lazos 2022), with the code itself as the constitution of a protocol-native community. The rules-as-code movement, and Catala in particular (Merigoux, Chataing, and Protzenko 2021), compiles statutory text into executable form. Ricardian contracts (Grigg 2004) and smart legal contract templates (Clack, Bakshi, and Braine 2016) bind machine-readable parameters to controlling legal prose – the same parallel-text construction used here. Workflow formalisms have modeled approval processes for decades (van der Aalst 1998). Statute has begun to meet the construction halfway: Delaware admits electronic databases, distributed ledgers included, for the stock ledger (8 Del. C. §224), and Wyoming charters entities managed in whole or in part by smart contract (Wyo. Stat. §17-31-101 et seq.). What this paper assembles for ordinary corporations under existing law is the remaining piece: a jurisdiction-parameterized specification whose quorums and thresholds name their eligibility bases, specification identity that is content-addressed and bound inside every signed consent, and a non-compensating join for multi-entity actions.

Legal documents remain the authoritative source. The work is the extraction of their structural content into a typed, content-addressed, machine-verifiable form that runs in parallel with the legal text. The governance specification does not supersede the bylaws. It is a mechanical mirror of the bylaws, validated against them by lawyers, then used by machines to verify that governance requirements are satisfied.

The question “was this corporate action properly authorized?” has always had a definite answer, fixed by the governing documents, the facts of the action, and the jurisdiction. Governance-as-code changes the cost of obtaining it. Given the content-addressed specification, the signed attestations, and the eligibility snapshot, the answer is a computation. The lawyer’s validation splits along the same line the rules do: statutory defaults once per jurisdiction and entity form, the entity’s own overlay – bylaws, shareholder agreements – once per entity per version of those documents, each amendment producing a new specification and a new hash. Every validation is then amortized across the decisions taken under it. An entity that amends its bylaws once a year and acts hundreds of times under them buys hundreds of verifications for one validation.

References

Clack, C. D., Bakshi, V. A., and Braine, L. (2016). “Smart Contract Templates: Foundations, Design Landscape and Research Directions.” arXiv:1608.00771.

Grigg, I. (2004). “The Ricardian Contract.” In Proceedings of the First IEEE International Workshop on Electronic Contracting.

Hoare, C. A. R. (1985). Communicating Sequential Processes. Prentice Hall.

Kiayias, A. and Lazos, P. (2022). “SoK: Blockchain Governance.” In Proceedings of the 4th ACM Conference on Advances in Financial Technologies (AFT).

Lorgat, R. How Compliance Composes. Companion paper in this series.

Merigoux, D., Chataing, N., and Protzenko, J. (2021). “Catala: A Programming Language for the Law.” Proceedings of the ACM on Programming Languages, 5(ICFP).

Milner, R. (1989). Communication and Concurrency. Prentice Hall.

van der Aalst, W. M. P. (1998). “The Application of Petri Nets to Workflow Management.” Journal of Circuits, Systems and Computers, 8(1), 21-66.