AI systems as infrastructure raise encoded-objective-law challenges that traditional enterprises do not face. When a system makes decisions (content moderation, lending approval, job candidate ranking), and those decisions are made by trained models rather than by humans applying rules, the operability test becomes harder to satisfy. This sidebar examines how Resilient Objectivism (RO) applies encoded objective law (1.2.2) to AI-augmented systems, drawing on the four operability conditions established in the main article (2.3D.2).
The Core Problem: Models vs. Rules
A rule-based system makes decisions by following instructions: "if income > X, approve loan." You can audit the rule. You can verify it is being followed. You can change it.
A trained model makes decisions by pattern-matching: given all the historical features, predict the outcome. The model has millions of parameters. You cannot interrogate it with the same clarity. You can measure accuracy on test data, but you cannot easily explain why a specific individual received a specific decision.
Encoded objective law requires auditability. But AI model decisions are notoriously difficult to audit. The challenge is not philosophical—it is architectural. How do we engineer auditability when the decision-maker is a statistical function, not a human applying transparent rules?
Traceability Under AI Conditions
When a model makes a decision, what trace remains? Can you reconstruct why it made that choice?
Under the traceability requirement, every model decision must be recorded immutably with its full context. This means: model version, input features, confidence score, decision timestamp. When you change the model in March and decisions shift, stakeholders can see exactly what changed. For any given decision, the input features are published—not raw customer data, but the feature set considered. "Age, income, credit score" is publishable; "face detected" should explain why face is a feature at all.
Confidence scores are included in the record. If the model is highly uncertain (60% vs. 40%), that uncertainty is visible in the decision, not hidden behind a binary yes-or-no. This signals to the decision-recipient that the system itself had doubts.
Consider a lending model that approves a loan application. The trace reads: "Model v3.1, approved, confidence 85%, features [age, income, credit_score, employment_type, debt_ratio], timestamp 17 March 2026 13:47:22Z." A customer can see this. They cannot immediately know why the model weighed employment_type heavily. But they can request an explanation and challenge the decision if the explanation seems discriminatory. The trace itself is not explanatory—it is evidentiary. It grounds the decision in auditable facts.
Auditability Under AI Conditions
Even if you have a trace, can a third party audit the model's fairness without access to proprietary training data or model weights?
Bias audits must be independent. This means hiring external auditors (academic, third-party) to test whether the model discriminates, with published findings. It means publishing test suites that show how the model handles edge cases. Stakeholders can see: "We tested 10,000 cases where applicants had gaps in employment. Model approved X%, rejected Y%. Approval rate differed by gender by Z%." The stakes of the decision determine how detailed this must be. A content moderation model can publish broader aggregates; a lending model must publish disaggregated performance by protected characteristics.
Explainability is built in from design. If the model cannot explain its decision in customer-understandable terms, it is not ready for deployment. This sometimes means using interpretable models (decision trees, rule-based) where possible, and explainability layers (LIME, Shapley values) where neural networks are necessary. The tradeoff between accuracy and interpretability is real—addressed separately below—but it cannot be resolved by choosing obscurity.
A model card is published for every system, similar to nutrition labels on food. It summarizes: what is this model trained for? What data was it trained on? Known limitations? Performance on different subgroups? Recommended uses? A hiring algorithm's model card reads: "Trained on 10 years of internal hiring data. Predicts 2-year retention. Performance: 82% accuracy overall. Accuracy by gender: M 84%, F 81% (statistically significant difference). Accuracy by age group: 18–30 81%, 31–50 83%, 50+ 79% (difference may reflect training data imbalance). Known limitation: model may learn from historical discrimination if hiring data did. Recommended use: initial screening. Do not use as sole hiring criterion. Human review required." This is transparency. Stakeholders know the tradeoffs and the model's limitations.
Survivability Under AI Conditions
If the trained model depends on your infrastructure, proprietary hardware, or specialized personnel, the system is not survivable. What happens if the vendor disappears? If the API goes down? If the hardware becomes obsolete?
Models must not be proprietary. Use open-source architectures. Train on documented data. Publish model weights so the system is reproducible. Model inference must be portable, using standardized formats (ONNX, TensorFlow SavedModel) so the model can run on different systems. The retraining pipeline that produced the original model is documented so that if new data arrives or competitors want to build equivalent models, the path is clear.
Fallback rules exist for degradation. If the model becomes unavailable, what happens? Can the system fall back to rules-based decisions? Slower decisions are better than no decisions. A content moderation system that depends entirely on a proprietary vendor's API has no fallback. A system that publishes fallback regex patterns for harmful content can continue, albeit more coarsely, if the model fails.
A content moderation example: "Model: open-source, pretrained transformer, fine-tuned on 100k labeled examples. Weights published. Inference code open-source. If inference unavailable, fallback: flag content matching these regex patterns for human review." A competitor or successor can stand up equivalent moderation in weeks, not years. The system survives the original operator.
Recoverability Under AI Conditions
When a model makes systematic errors—all women rejected, all young people approved—how do you identify and recover?
Continuous monitoring measures model performance on ongoing decisions, not just historical test accuracy. If approval rate diverges across groups, trigger alert. Decision audits sample recent decisions and ask beneficiaries: did the model treat you fairly? If complaints cluster (all rejections from a particular postal code), investigate whether the model is proxying for protected characteristics.
Retraining is triggered when performance degrades or bias appears. The retraining is documented. What changed and why are published. User appeals are supported: every high-stakes decision can be appealed to a human reviewer who has authority to override the model. Appeals are tracked. If the human reverses the model's decision frequently, investigate whether the model needs retraining or whether the rules underlying the human review have drifted.
A lending example illustrates the practice: A model's approval rate for applicants aged 50+ drops from 45% to 30% after retraining. Investigation finds that new training data overweighted age correlation. The fix is retraining with balanced age representation. The publication reads: "Retraining 17 March 2026: identified age bias in model v3.0. Retrained on balanced data. New model v3.1 approved 17 April 2026. Affected applicants eligible for appeal." This is not a one-time correction. It is a continuous feedback loop that surfaces bias when it emerges.
Consent and AI Systems
AI decisions raise consent questions that rule-based systems do not, because the decision-maker is not visibly human. Consent under AI requires three conditions.
First, participants must understand they are being evaluated by a model. "Your loan decision will be made by a statistical model, not a human, unless you request human review." If this is not disclosed, consent is not real. The knowledge that decisions are algorithmic, not deliberative, changes the nature of what is being consented to.
Second, participants must have genuine recourse. A participant rejected by a model should be able to appeal to a human, and the human should have authority to override the model. If the system is "model decides, human rubber-stamps," the appeal is theater. The appeal authority must be real, and appeal decisions must be tracked so they inform model retraining.
Third, for high-stakes decisions, participants should have the option to opt out of model evaluation entirely. Low-stakes decisions (content recommendation, mild moderation) may not require this. High-stakes decisions (lending, employment, benefits) should. A job candidate can request: "I prefer human review rather than model screening." The system accommodates this, even if it is more expensive. This is consent—the choice to be evaluated by a different mechanism, with full knowledge of the consequences.
The Practice: AI Under Encoded Objective Law
An enterprise using AI systems as infrastructure practices encoded objective law by publishing a model card for every high-stakes decision system, summarizing what the model predicts, what data it was trained on, and known limitations. It records model traces for every decision: version, inputs, confidence, timestamp. Traceability is automatic, not added on demand.
It conducts independent audits of model fairness—not internal audits, independent ones—with published findings. It uses interpretable models where possible, explainability layers where necessary. If a decision affects someone materially, they should understand in principle why it was made.
It maintains fallback rules. If the model is unavailable, the system degrades gracefully. Decisions do not stop. It monitors live performance: continuous measurement of model behavior, with alerts if fairness metrics diverge. It supports appeals to humans: every high-stakes model decision is appealable to a human with override authority. And it discloses model use: participants understand when they are being evaluated by models, not humans.
The practice is not perfect fairness. It is fairness designed so that bias is visible, measurable, and remediable. See also the organizational encoded objective law framework (2.3C.3) for the broader enforce-in-code principle, and Phase I treatment of AI systems (1.2.2-4) for the foundational philosophical argument.
Honest Tradeoffs Under AI
AI systems present genuine tradeoffs that cannot be entirely resolved.
Accuracy vs. Interpretability. A neural network may be 90% accurate but hard to explain. A decision tree may be 80% accurate but fully transparent. Which matters more depends on stakes and domain. For loan decisions, transparency matters more—the cost of an incorrect decision to an individual is high. For content recommendation, accuracy may dominate—the cost of a wrong recommendation is low. Name your choice. Do not claim to have optimized both equally when you have optimized one at the expense of the other.
Speed vs. Fairness. Models are fast (milliseconds). Human review is slow (days). If you insist that all decisions be human-reviewed, the system slows dramatically. If all decisions are automated, bias detection slows (it requires aggregation over many decisions). You cannot optimize for both. The practice is acknowledging the tradeoff and choosing consciously where speed matters and where fairness does.
Personalization vs. Privacy. The best models are trained on the most data. But the most data is the most invasive. You can train a model on rich behavioral data and make great recommendations, at the cost of privacy. Or collect minimally and accept worse predictions. Privacy by design (1.2.4) is one approach; transparent data governance is another. Choose consciously. Do not market privacy-respecting personalization as a substitute for the real tradeoff.
Performance on Aggregate vs. Subgroups. A model can be highly accurate overall but perform worse for minority groups. You cannot typically optimize for both equally. A model that is 82% accurate overall might be 84% accurate for the majority group and 76% for a minority group. You must name what you are optimizing for. The honest statement is: "We optimized for aggregate accuracy. This resulted in worse performance for subgroup X. We accepted this tradeoff because [reason]."
The practice is making these tradeoffs explicit and honest about the choice. It is not claiming to have made them disappear.
Change Log
- 17 Mar 26 — Initial publication.
- 19 Mar 26 — Updated the heading and subtitle for clarity, and added cross-references to related units. Changed the example model version numbers (from v2.3A.1/v2.3A.0 to v3.1/v3.0) to avoid confusion with the unit-numbering scheme. Converted bulleted lists throughout — including the "Consent and AI Systems" and tradeoffs sections — into prose paragraphs.