The Encoded Objective Law Assessment Grid 2.3D.2-1

The encoded objective law assessment grid translates abstract principle into concrete evaluation tool. It provides a systematic way to audit whether any system — financial, governance, product, civic infrastructure — encodes moral constraints into architecture or relies on institutional virtue. This sidebar operationalizes the dual-framework assessment introduced in the main article (2.3D.2): the four operability conditions that determine structural protocol integrity, and the six moral questions that test whether the protocol embodies Resilient Objectivism (RO) ethical commitments.

The grid serves three purposes. First, it creates a shared diagnostic vocabulary for teams assessing whether a system should move toward protocol-based governance. Second, it surfaces honest tradeoffs — what you are gaining and what you are sacrificing by choosing encoded objective law over institutional discretion. Third, it enables periodic review: return to the grid annually or after significant failures to track progress and identify new gaps as the system evolves.

Two Complementary Frameworks

The assessment grid operates in two layers. The operability conditions test whether the system is technically protocol-based. The moral questions test whether the protocol's architecture aligns with RO's ethical commitments. Both are necessary. A system can be operationally sound but ethically misaligned. Conversely, a system can intend moral correctness but lack the structural mechanisms to deliver it under adversarial conditions.

The Operability Conditions

These four conditions — drawn from the organizational enforce-in-code flow (2.3C.3) and extended to civic scale — determine whether a system can function as genuine protocol-based governance.

Traceability means every transaction, decision, and state change leaves a permanent record. Not a recoverable record — a permanent one. An append-only ledger. You cannot rewrite history. You can only add to it. In civic governance, this means every budget decision is recorded with date, authority, amount, recipient, and stated rationale. Every personnel consequence is logged: who made the decision, what policy governed it, what evidence supported it, when. Every exception to a rule is recorded: what the rule was, what exception was granted, who authorized it, why. Every change to a rule (policy, procedure, governance structure) is recorded with before/after versions and effective dates. A person examining your organization's records in five years should be able to reconstruct how decisions were made, what rules were in effect, what exceptions existed, and who decided what. If not, your traceability is incomplete.

Auditability means those records can be independently verified. A third party with access to the records can prove or disprove material claims about the system. In civic governance, this means budget claims are auditable: "We spent $X on purpose Y" can be verified through receipts, contracts, and payment records. Policy compliance is auditable: "We followed procedure P for decision D" can be verified by checking the record against the stated procedure. Impact claims are auditable: "This governance structure reduces capture risk" can be tested by examining decision patterns, appeal frequencies, and whether rules are actually being renewed or hardening. Personnel decisions are auditable: "This dismissal followed the stated process" can be verified by checking that notice was given, appeals were offered, and the decision was documented. Auditability requires transparency, not just record-keeping. Records that are kept secret cannot be audited. Records must be accessible to relevant parties — employees, stakeholders, compliance bodies, courts if needed. If someone disputes a key claim about your organization, can they get access to evidence that proves or disproves it? If not, auditability is incomplete.

Survivability means the system can operate even if key institutions fail. If the system depends on a particular server, a particular authority, or a particular person to function, the system is not survivable — it is architecture dependent. In civic governance, this means key processes should be documented so that departing individuals do not take critical knowledge with them. Knowledge is captured in procedures, not stored in people. Critical decision-making should have redundancy: if the board chair becomes incapacitated, there is a documented succession process. Data should be stored redundantly and accessible even if systems fail — not just backup, but accessible backup that participants can verify. The governance structure itself should survive the departure of key people. Policies are recorded, procedures are written, authority is distributed — the system does not depend on the integrity or presence of specific people. If your CEO left tomorrow and was unavailable, would the organization grind to a halt? If a key server crashed, would critical data be irretrievable? If the audit director became unavailable, would governance freeze? If yes to any of these, survivability is incomplete.

Recoverability means that when something does fail or corrupt, you can recover. Can you restore data from backup? Can you restart a process from a known point? Can you identify and correct a failure without starting from zero? In civic governance, this means personnel records should be backed up and restorable — if a database is corrupted, you can restore from backup and know what data was lost and when. Policy documents should be version-controlled: if someone accidentally edits the wrong version, you can restore from prior versions and identify what changed. Financial records should be verified against backups: if discrepancies appear, you can reconcile against prior records and identify when the divergence started. Governance decisions should be reconstructible: if someone claims a decision was made, you can show the record; if a decision is called into question, you can show the evidence that justified it. When something goes wrong in your organization (data loss, decision reversal, policy violation), can you explain what went wrong and recover? Or do you learn about it later and struggle to reconstruct what happened?

The Moral Questions

These six questions — derived from RO's ethical commitments and tested against the threat model of adversarial operation — test whether the protocol's architecture embodies genuine moral constraints rather than merely appearing to do so.

Does it encode non-coercion? Participation in the system should be genuinely voluntary. Exit should be possible without penalty. Participants should not be compelled to participate, and withdrawal should not cascade into forfeiture of prior contributions or rights. This is encoded objective law's own ethical foundation: coercion itself — not just coercive outcomes — must be structurally prevented. A protocol that locks participants in through technical or contractual impossibility of exit is a protocol that has violated the non-coercion condition, regardless of how transparent its other operations are.

Does it enable verification without permission? Claims about the system should be independently checkable without requiring the claimant's cooperation, institutional trust, or special access. A protocol that requires you to ask the authority "is this claim true?" before you can verify it is not really a protocol — it is institutional theater. Verification without permission means the tools and information needed to audit the system are available to stakeholders without permission from incumbents. This is the epistemic independence that makes auditability meaningful.

Does it resist capture? Can a single authority redirect the system to serve its own interests without detection or resistance? A protocol susceptible to unilateral capture — where one participant or institution can rewrite rules, redirect resources, or change governance in secret — is a protocol that has failed structurally. Capture resistance does not mean perfect prevention; it means that capture attempts become visible and costly and require consensus to succeed. A system where capture is silent and easy has not achieved protocol-based governance.

Does it fail gracefully? When something breaks — a node goes offline, a key person becomes incapacitated, a component malfunctions — does the system degrade incrementally or cascade catastrophically? A protocol whose failure propagates widely (one node failure brings down the whole system) or creates irreversible damage (one person's error destroys all historical records) has not achieved structural resilience. Graceful failure means broken parts can be isolated, the system continues functioning at reduced capacity, and recovery does not require wholesale reconstruction.

Does it create new moral hazards? The protocol's own structure should not generate incentive misalignments that did not exist before and that the protocol itself cannot address. Some tradeoffs between the operability conditions are unavoidable — speed versus security, capital efficiency versus decentralization. But if the protocol creates novel incentives for hidden behavior (e.g., miners conspiring secretly, officials colluding to corrupt records without detection, market participants gaming a system designed to prevent gaming), the protocol has introduced new moral hazards that the underlying institutional virtue must manage. A truly protocol-based system pushes moral hazards into the open where they can be seen and addressed, rather than creating hidden temptations.

Does it provide contestability and remedy? Canonical encoded-objective-law.md names this the adjudication requirement — co-equal with the encoding question itself, not a lesser or optional sixth item. A rule known in advance and an identifiable basis for a decision are not enough if no one outside the party that executed the decision can review it, and no remedy exists for an error that was in principle reversible. A protocol can score perfectly on the first five questions and still fail this one — Bitcoin, this sidebar's own worked exemplar in the main article (2.3D.2), is exactly that case: transactions are irreversible by design, with no review body outside the transacting parties. Encoding a constraint into architecture and providing a way to correct architecture's own mistakes are different achievements, and a system that only does the first has automated the error along with the rule.

Assessment Grid: Two Tables for Complete Diagnosis

Table 2.3D.2-1a: Operability Conditions Assessment

Structural protocol integrity — The technical conditions that must hold for governance to be genuinely protocol-based

Table 2.3D.2-1b: Moral Questions Assessment

Ethical alignment — Whether the protocol's architecture embodies RO's ethical commitments under adversarial conditions

The Grid in Practice

Step 1: Name Your System and Its Moral Constraints

Begin by naming what the system does and what moral constraints matter. For a public authority processing unemployment benefits, the system's function is eligibility verification and benefit distribution. The moral constraints are these: do not deny benefits falsely, do not double-pay, do not expose personal data, do not discriminate. For a fintech lending platform, the system is lending capital allocation and repayment monitoring. The moral constraints: do not charge undisclosed fees, do not lock borrowers in, do not misrepresent risk, settle fairly. For a social network, the system is community communication and content curation. The moral constraints: do not manipulate engagement through hidden signals, do not export user data without consent, do not practice surveillance.

Being specific about moral constraints is more valuable than being exhaustive. You will not be perfect. The grid is a diagnostic tool, not a completeness checklist.

Step 2: Fill in the Grid

For each operability condition and each moral question, assess where your system stands now. Do you have traceability? Are decisions recorded and permanent? Can stakeholders access the records? Can anyone verify claims without requiring institutional trust? Is the system dependent on specific people? What happens if they leave? When things break, can you recover? The grid columns are simple: current state (where you are), target state (where you want to be), gap (the distance between them), and remediation (what would it take to close the gap).

Step 3: Identify Honest Tradeoffs

For each condition or question where you score below target, identify the tradeoff you are making and whether it is acceptable. If a social network wants full auditability but current target is limited, the current state is this: "Our algorithm recommends content. We cannot publish details because it reveals intellectual property and exposes us to gaming." The tradeoff is this: "We chose opacity to protect competitive advantage. The tradeoff is that users cannot verify we are not discriminating or manipulating." Is this acceptable? Only if you acknowledge it explicitly. If you claim "our algorithm is completely fair and transparent" while your architecture is designed for opacity, you are being dishonest about the tradeoff. If you say "we are trading verifiability for competitive advantage, and users should know that before they depend on our platform," you are being honest. The grid surfaces honesty.

If a government agency wants full survivability but current target is limited, the current state might be this: "A specific individual, the Census Director, has authority to approve exceptions to data collection. If the Director is unavailable, exceptions cannot be approved." The tradeoff is this: "We chose bottleneck authority to prevent circumvention of collection rules. The tradeoff is that the system is personality-dependent." Is this acceptable? Only if you address it: define succession process, document decision criteria so that successors can apply them, or delegate approval authority to a standing committee. Do not let organizational survivability depend on the presence of a single person if you claim to be practicing encoded objective law.

Step 4: Design Remediation Pathways

For each gap between current and target state, name what it would take to close the gap. If you have an auditability gap — current state is "We collect data on police officer decisions (stops, searches, use of force), we audit internally but do not publish raw data" — and target is "Stakeholders can independently audit police decisions for fairness," then the remediation pathway might unfold over years. Year 1: publish aggregate statistics (stops by neighborhood, demographic, outcome); hire independent auditors to review internal processes; fund external research on bias. Year 2: publish individual incident records with identifying information removed (badge number instead of name, date without precise location); researchers can reconstruct patterns. Year 3: publish full incident records with identifying information, accessible through public-records requests; strengthen data minimization so you do not collect optional information that enables discriminatory use. Each year, transparency increases and auditability becomes more complete.

Or if you have a survivability gap — current state is "Our product depends on a proprietary data format that only our engineers understand" — and target is "Our product uses open formats that competitors and community members can maintain," then remediation might look like this. Year 1: publish the data format specification and provide export tools; train team members on the spec so knowledge is distributed. Year 2: migrate to a standard format (JSON schema, semantic web ontology); prove that the open format preserves all functionality. Year 3: support multiple implementations of the format, including by third parties; participate in standards governance so the format is maintained independent of your company.

Three Worked Examples

The following examples show how the grid applies to real systems. Each example fills in both the operability conditions and moral questions, identifies tradeoffs, and maps remediation pathways.

Table 2.3D.2-1c: Financial Ledger (Bank)

Example system: A bank managing customer accounts, transactions, and financial records

Table 2.3D.2-1d: Public Grant Program

Example system: A government body awarding competitive grants, evaluating applications, and managing funds

Table 2.3D.2-1e: Content Moderation Platform

Example system: A social network or community platform managing user-generated content, disputes, and appeals

Common Grid Failures

The Phantom Tradeoff is claiming "We wanted auditability but we chose opacity for security" when the real question is whether the tradeoff is genuine. Real security-auditability tradeoffs exist. But security has become the default excuse for opacity. The test is simple: if someone genuinely knowledgeable attempted to audit, could they? If not, the tradeoff may be phantom. Be specific: what exact security risk does transparency create? Can you design around it?

The Aspirational Target happens when you set target state as "full encoded objective law" when the system is actually designed for human judgment and discretion. Misaligned targets lead to frustration and false hope. If the system needs human discretion because police officers should have judgment in their work or prosecutors need case-by-case assessment, then target state might be "high traceability and auditability of decisions, with public appeal mechanisms" — not "protocol-based decision-making that removes human judgment." The grid measures progress toward honestly defined targets, not against impossible ideals.

The Unexamined Gap is identifying gaps but not acknowledging remediation costs. Closing a traceability gap might require a year of engineering. Closing an auditability gap might require publishing data that competitors could exploit. Closing a survivability gap might mean distributed systems that are slower and more expensive to run. Do not pretend gaps close for free. Acknowledge costs. Make choices explicitly. "We are choosing to remain opaque because the remediation cost exceeds current budget and this function is not critical enough to justify the investment" is honest. "We will become transparent sometime" is not.

The Unmeasured Condition is assessing conditions by feeling rather than evidence. "We think we have high survivability because we have good documentation." Real test: did someone new actually take over a role using only the documentation? Did they succeed? Measurement is more honest than assumption.

Using the Grid Over Time

The encoded objective law assessment grid is not a one-time audit. It is a living tool.

Annually, review each condition and each moral question. Update current state. Has it improved? Have new gaps appeared? Have external changes (regulatory, competitive, technological) affected the conditions? Tracking changes over time reveals whether the system is genuinely becoming more robust or merely claiming to.

After incidents, when a failure occurs (data breach, moderation error, fraud, system outage), update the grid to assess which conditions the failure revealed. Example: "We discovered that only one person understood how our backup system works. This revealed low survivability." Use failures as data points for improvement.

During strategic planning, when choosing architecture or governance changes, use the grid to evaluate options. "Option A is cheaper but scores lower on auditability. Option B costs more but enables independent verification. Which tradeoff are we willing to make?" Structured evaluation prevents drift toward the path of least resistance.

For stakeholder communication, publish your grid. Show where you stand, what tradeoffs you are making, what remediation you plan. This is transparency about governance itself. It says "here is how we are designing for integrity, here is what we are sacrificing for other values, here is where we are vulnerable, here is how we are fixing it." Systems that are honest about their tradeoffs are far more credible than systems that claim to be fully ethical while designed for opacity.