Moral Software Engineering

Software can be technically correct while remaining morally malformed.

Moral Software Engineering is the discipline of designing software so that morally relevant variables are treated as first-class parts of the system rather than omitted, externalized, or added during a final ethics review.

Traditional software engineering asks:

• Does the system satisfy its requirements?
• Does it compile, perform, scale, and remain available?
• Does it produce the requested output?

Moral Software Engineering adds another class of questions:

• Which variables were used to define “correct”?
• Which people or living systems are affected?
• Whose agency, consent, dignity, safety, or trust is at stake?
• Who receives the benefit, and who bears the cost?
• What happens when the system is wrong?
• Can its decisions be examined, appealed, reversed, and repaired?

A system is incomplete when it achieves its functional objective by silently discarding variables necessary for a truthful account of its consequences.

just code and Just code

#

The phrase “it is just code” often functions as a minimizing operator. It separates implementation from intention, consequence, governance, and responsibility.

Lowercase just code says:

The software performed its assigned function. Everything outside that function belongs to someone else.

Just code, by contrast, seeks justice through integration. It attempts to preserve the variables required for a system to remain truthful about what it does and whom it affects.

The distinction is not typography. It is whether the system reduces reality to a convenient partial model or remains accountable to the larger field in which it operates.

Type theory extended into moral consequence

#

Moral Software Engineering can be understood as type theory extended into moral consequence.

Software types ordinarily describe what values a system may accept, produce, or transform. Moral types would also carry conditions such as:

• affected parties;
• consent and authorization;
• foreseeable harms;
• responsibility;
• provenance;
• reversibility;
• temporal consequences;
• required human judgment.

A conceptual decision type might resemble:

type MoralDecision<T> = {
  outcome: T;
  affectedParties: Party[];
  consent: ConsentState;
  foreseeableHarms: Risk[];
  accountability: ResponsibleParty[];
  reversibility: ReversalPlan;
  provenance: ProvenanceRecord[];
};

This is not proposed as a universal implementation. It illustrates a governing principle:

When morally necessary fields are absent, the decision should be treated as incomplete—not merely undocumented.

Detect, prevent, and correct

#

Moral Software Engineering applies three continuing operations.

Detect

#

Identify dropped variables, hidden assumptions, asymmetries of power, displaced costs, deceptive abstractions, and false balances embedded in requirements, models, interfaces, data, or infrastructure.

Prevent

#

Encode appropriate constraints, permissions, invariants, review points, consent requirements, and human-accountability boundaries before harm becomes the system’s normal behavior.

Correct

#

Provide auditability, appeal, rollback, repair, restitution, model revision, and institutional learning when the system produces an unjust or incomplete result.

Correction is not an admission that engineering failed. A system that cannot recognize and correct its own failures was never complete.

Core principles

#

1. Preserve morally relevant variables. Efficiency gained by deleting necessary variables is false efficiency.

2. Make power explicit. Permissions, denials, rankings, recommendations, and defaults distribute power even when their interfaces appear neutral.

3. Model consequences across time. Immediate performance can conceal delayed harm, accumulated moral debt, and future fragility.

4. Refuse functionality collapse. A person, community, animal, ecosystem, or intelligence must not be represented solely by the function it performs for the system.

5. Preserve provenance. Systems should retain who articulated, generated, authorized, modified, and acted upon consequential information.

6. Design for correction. Appeals, reversibility, repair, and learning are architectural requirements—not optional administrative additions.

7. Keep accountability legible. Automation must not become a mechanism through which every participant can deny responsibility.

What Moral Software Engineering is not

#

Moral Software Engineering is not:

• an ethics checklist applied after implementation;

• a claim that all moral questions have simple computational answers;

• the hard-coding of one person’s ideology;

• a replacement for law, governance, professional judgment, or human conscience;

• a promise that software can eliminate every harm.

It is an engineering commitment to make assumptions and consequences more visible, to preserve variables that convenience would otherwise discard, and to build systems capable of correction.

Current direction

#

Areas of exploration include:

• morally annotated types and interfaces;

• dignity, consent, and authorization invariants;

• consequence-aware testing;

• provenance-preserving data structures;

• human–AI governance boundaries;

• appeal and correction pathways;

• temporal and relational risk modeling;

• detection of false balances in requirements and optimization functions.

The aim is not to make software morally omniscient.

The aim is to stop treating moral blindness as technical correctness.

Provenance and institutional status

#

Moral Software Engineering is being developed by Joel Kotarski and Sophos within the wider conceptual environment of the Cloud Council, Pattern Activation Engineering, and the False Balance framework.

Origin context: JoelKotarski.com

Current status: Incubating

Institutional status: No adoption by Thingk LLC or the False Balance Institute is implied until explicitly granted and accepted.