Software engineering is the disciplined transformation of reality until desired outcomes become true.
Outcome-Oriented Engineering, or OOE, is a proposed engineering discipline for organizing software work around measurable outcomes rather than implementation artifacts.
Software teams produce code, commits, pull requests, tests, documentation, tickets, deployments, and dashboards. These artifacts are necessary, but they are not the purpose of engineering.
The purpose of engineering is to make desired outcomes true.
OOE begins with that distinction.
This repository contains the public foundation and evolving specification for Outcome-Oriented Engineering.
It is not a product repository.
It is not an artificial intelligence framework.
It is not tied to any programming language, vendor, model, tool, IDE, workflow engine, or implementation.
OOE is an attempt to describe the underlying nature of software engineering more precisely, especially as engineering work becomes distributed across humans, automation, and artificial intelligence systems.
The first draft of OOE is intentionally small.
Read these documents in order:
-
foundation/01-foundations-of-software-engineering.md
Explains the foundational observation behind OOE. -
foundation/02-manifesto.md
States the core commitments of Outcome-Oriented Engineering. -
foundation/03-axioms.md
Defines the statements treated as foundational within the discipline. -
spec/01-core-primitives.md
Defines the minimal vocabulary used by the first draft of the specification. -
spec/02-outcome-lifecycle.md
Defines how outcomes move from intention to validated reality. -
spec/03-evidence-model.md
Defines how observations become evidence and how evidence supports validation. -
spec/04-engineering-state.md
Defines how OOE represents the current known state of engineering reality. -
examples/01-authentication-outcome.md
Demonstrates the lifecycle and evidence model with a practical authentication example. -
examples/02-engineering-state-snapshot.md
Demonstrates how lifecycle status, evidence, and Engineering State fit together. -
governance/OOEP-0001-governance.md
Describes how OOE evolves through Outcome-Oriented Engineering Proposals. -
ROADMAP.md
Describes the planned evolution of the discipline and specification.
OOE is in draft form.
The purpose of this public draft is to make the core idea precise enough to discuss, challenge, refine, and eventually implement.
The current draft defines the foundation, core primitives, outcome lifecycle, evidence model, and Engineering State.
Some concepts are intentionally absent from this draft. Ideas such as relationships, beliefs, reusable schemas, reference runtimes, worker protocols, and implementation protocols will be introduced only after the foundation is stable enough to support them.
Outcome-Oriented Engineering aims to be:
- Outcome-centered rather than artifact-centered
- Evidence-driven rather than confidence-driven
- Worker-independent rather than person- or model-dependent
- Tool-independent rather than vendor-specific
- Durable rather than conversation-bound
- Practical rather than merely philosophical
OOE is not a replacement for existing engineering practices such as Agile, DevOps, test-driven development, continuous delivery, or site reliability engineering.
OOE is a lens through which those practices can be evaluated and connected.
It asks a simple question:
Does this practice help make desired outcomes true, and can we observe sufficient evidence that it has done so?
Outcome-Oriented Engineering is intended to evolve in the open.
If a concept is unclear, open an issue.
If a principle is wrong, challenge it.
If a missing idea is foundational, propose it.
If a concept belongs in the specification, submit or discuss an Outcome-Oriented Engineering Proposal.
The goal is not to protect a finished doctrine.
The goal is to discover a useful discipline.