Your Bylaws Are a Syntax Tree

Corporate bylaws are written in English because humans have historically been the only interpreters that mattered. Once software agents need to follow those rules, the limitations of prose become obvious. English is flexible, but it is also ambiguous and context-dependent.

Rules have always been trees

Read any set of corporate bylaws carefully and you’ll find the same structure that Backus and Naur described. Rules compose. Conditions nest. Exceptions modify defaults. Authority flows through a hierarchy.

“The Board may authorize expenditures up to $50,000 without shareholder approval, except that expenditures related to executive compensation require a majority vote of independent directors, and expenditures exceeding $10,000 that are not in the approved annual budget require the CEO’s prior written consent.”

This isn’t prose. This is a tree:

authorize_expenditure
├── default: Board authority
├── condition: amount <= $50,000
├── exception: executive_compensation
│   └── requires: independent_director_majority_vote
└── exception: not_in_budget AND amount > $10,000
    └── requires: ceo_written_consent

Every governance document is a forest of these trees, tangled together by cross-references, modified by amendments, and interpreted through decades of case law. Lawyers are human parsers. They read the grammar, resolve the ambiguities, and produce a judgment: this action is authorized, or it isn’t.

This works. It has worked for centuries. But it doesn’t scale to a world where the entity executing the action is a software agent that needs to make authorization decisions in milliseconds, thousands of times a day.

The governance AST

TheCorporation’s governance engine is built on a literal abstract syntax tree: a JSON document that encodes the corporation’s authority model in a machine-evaluable structure.

At its root, the AST defines three concerns:

Tier defaults. Every capability a corporation can exercise, from maintain_books_records to issue_equity, has a default authority tier. Tier 1 actions execute autonomously. Tier 2 actions require recorded approval. Tier 3 actions are reserved for the board or principal.

Non-delegable actions. Twelve capabilities can never be delegated regardless of context, including amending the charter, issuing equity, dissolving the entity, and settling litigation. These are hard stops that no runtime configuration can override.

Rules. Escalation conditions, lane boundaries, and operational constraints modify the defaults based on runtime context. A Tier 1 action can escalate to Tier 2 if certain conditions are met.

The AST is the authoritative statement of what the corporation’s agents can and cannot do, expressed in a medium that both humans and machines can evaluate.

Parse, don’t interpret

The critical insight is that many governance rules should be parsed rather than interpreted. When a lawyer reads a bylaw, they apply judgment and resolve ambiguity. When the governance engine evaluates an intent against the AST, it applies the rules as written and produces a deterministic result.

This is a feature, not a limitation. The actions that should be mechanical, such as paying a recurring bill, filing a tax return, or renewing a registered agent appointment, benefit from speed, consistency, and auditability.

The actions that do require interpretation — strategic decisions, novel situations, ambiguous circumstances — are exactly the ones the AST classifies as Tier 2 or Tier 3. They get escalated to humans. The AST doesn’t replace judgment. It identifies where judgment is needed and routes accordingly.

Context-sensitive escalation

A static tier assignment isn’t enough. The same action can require different authority depending on context. Signing an NDA using an approved template is routine. Signing an NDA with modified indemnification clauses is not. Renewing a subscription at the same price is Tier 1. Renewing at a 15% markup is Tier 2.

The AST handles this through escalation rules and lane conditions:

{
  "lane_id": "lane-3.3-renewal",
  "capability": "pay_recurring_obligation",
  "checks": [
    {
      "field": "context.priceIncreasePercent",
      "op": "lte",
      "value": 10,
      "message": "Price increase exceeds 10% limit"
    }
  ]
}

This is a lane boundary. The agent can autonomously renew a subscription — but only if the price increase is 10% or less. If the vendor raises the price by 15%, the lane condition fails and the action escalates to Tier 2. The agent doesn’t silently accept the increase. It asks for approval.

Escalation is one-directional. Rules can raise an action’s tier, never lower it. A Tier 1 action can become Tier 2 if context demands it, but a Tier 3 action never becomes Tier 2 because context is favorable.

Traceability to the document

Every policy decision carries clause references that trace the decision back to the specific AST nodes that produced it. When the engine decides that an action requires Tier 2 approval, the response includes references like delegation.authority_tiers.tier2 and rule.escalation.template-not-approved.

This matters for audits. It matters for board oversight. And it matters for the agents themselves — an agent that receives a “denied” decision can examine the clause references to understand why it was denied and what would need to change for the action to be authorized.

Bylaws that compile

Expressing governance rules in a parseable format forces ambiguities to resolve. A bylaw that says “reasonable expenditures may be authorized at the discretion of the officer” may be valid English, but it is not a useful machine instruction.

The result is governance that compiles. If the AST parses, the rules are internally consistent. If the policy engine evaluates without error, the authority model is complete. If the tests pass, the governance framework is mechanically correct.

Your bylaws have always contained a syntax tree. The difference is that now the system treats them like one.