Metrics schema - Certified and Certifying Authority

[NitinRJoshi]

In large organizations, there are multiple variants of the same metric / KPI. Governance organizations do a lot of hard work in certifying the standard definitions. Metrics schema can be enhanced to capture whether it is certified and who is the certifying authority.

[peterkalk]

Three open threads are asking for the same thing

This discussion (#53), issue #92 on a governance and reconciliation layer, and issue #305 on an
owner attribute are all circling one gap: the spec can express what a definition means, but not
who established it.

It may be worth noting why this keeps stalling while neighbouring requests do not. Issue #58
(personal data indicator) and #59 (confidentiality indicator), filed on the same day by the same
person as #305, were both answered eleven days later. Those are metadata about the data.
Ownership and certification are metadata about a decision, and a decision is a property of an
organisation rather than of a dataset. That is a genuinely different
kind of thing, and I suspect it is why it does not land in the existing object model rather than
why anyone objects to it.

Why it matters for the stated goal

The README motivates Ossie partly by AI agents "producing unreliable outputs grounded in
inconsistent business logic". Consistency and correctness are not the same property. Two tools can
agree perfectly on a definition that finance never approved. An agent acting on a consistent but
unapproved definition is not safer than one acting on an inconsistent one; it is confidently wrong
at scale, and there is no field in the document that would let a reviewer notice.

For context, I work with finance teams where a metric definition has to survive an audit
question, which is where this gap stops being theoretical. The practical question downstream is
always the same: when an agent produces a number and someone asks why it is that number, the
answer has to name a person, a date and a decision. Today that
answer lives outside the Ossie document, which means it does not travel with it.

A minimal proposal

Four optional fields on any metric or concept, no new object types:

owners: [finance-team]        # who maintains it (issue #305)
approved_by: j.smith@acme     # who established this definition as authoritative
approved_on: 2026-04-18       # when
lifecycle: approved           # draft | proposed | approved | deprecated

All four optional, so nothing breaks for producers that do not use them. A consumer that ignores
them behaves exactly as today. A consumer that reads them can refuse to serve, or flag, a
definition that nobody approved.

I would deliberately keep this descriptive. Ossie should record that a decision was made, not
prescribe an approval workflow. Who may approve what is an organisational matter and differs per
company; that it was approved, by whom and when, is interchange metadata like any other.