Methodology PapersIn functional hierarchies every unit owns a process, but no one owns the value flow that crosses units and is realized at the receiving actor. This paper, written for managers, product and engineering leaders and operations, presents the Æilus v2.0 role and process model as a way to make value ownership explicit without adding command layers. It sets out the six roles, the mandatory process groups and events, an artifact allocation per role, an adoption path, and the risks of role inflation, bureaucracy and value theatre with their safeguards.
value ownershipÆilus rolesValue Transformer OwnerValue System OwnerFlow Owneroperating cycleartifacts and reportsvalue theatre
Methodology PapersOKRs set direction and KPIs control quality, but in management systems all objectives look equal, so the convenient and the measurable tend to win over the important. This paper, for managers and product, engineering, operations and strategy leaders, proposes a value layer over existing goals: each objective and indicator receives a planned value and an anti-value estimate in Æ, tied to a named value system and owner, and is later checked against realized value. It gives the required record per objective, an eight-step adoption procedure, an illustrative example and safeguards against false precision and gaming.
OKRKPIprioritisationvalue currencyanti-valueplanned and realized valueaggregation policyGoodhart's law
Methodology PapersPractices copied from other organisations often fail to deliver, because a practice carries its form but not the value system that made it work. This paper, for managers and product and engineering leaders, defines a practice as a local value system with a declared value hypothesis, sets out when a practice is admissible under domain policies, and gives a structure for building and maintaining a practices collection.
practicesbest practicesdomainsdomain policiesadmissibilitypartial commensurabilitypractices cataloguevalue transformer
Methodology PapersVelocity, throughput and DORA-style delivery metrics describe how work moves through a pipeline, but not what value it delivers or what anti-value it creates. This paper gives product and engineering leaders a method for modelling a software product's value system with the Value System Schema (VSS) and the VSS Editor, and for comparing planned, realized and retrospective value per release. It covers flow resistance, leakage, shared nodes such as authorisation and API gateways, roles, cadence and the limits of the approach.
value system schemaVSS Editorsoftware deliveryplanned and realized valueanti-valueflow resistanceshared servicesdelivery metrics
