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.

[MikeCarlo]

Id also like to see approve_by as an array

as this might need to be across multiple people.

I do think you would also want the ability to track who is the knowledge expert on this metric, column, or the datasteward of this information

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
steward: [group, person]           # group or person who is responsible for maintaining or speaking to it's definition

[anykolaiszyn]

@peterkalk put his finger on the thing that keeps this thread stalling: ownership and certification are metadata about a decision, not about the data. Personal-data and confidentiality flags describe a column. "Finance approved this" describes an organization. The object model has a place for the first and not the second, and no amount of filing the same issue three times will change that until someone says it out loud. He did. +1 to all four fields, and +1 to @MikeCarlo on arrays and a steward.

I want to push on one word in the opening post, though, because it's doing more work than it looks: variants.

In large organizations, there are multiple variants of the same metric / KPI.

That's the whole problem, and lifecycle: approved doesn't solve it on its own. Picture three gross margins: product, services, consolidated. All three are real. All three are approved. The product lead signed one, the services lead signed another, the controller signed the third. Now a consumer opens the model, finds three metrics with lifecycle: approved and three different approved_by values, and someone asks the agent "what was our gross margin last quarter?"

What should it do? The four fields can't say. They record that each decision was made. They don't record the scope of each decision, and scope is the part a consumer actually needs.

Certification is never a boolean in practice. Nobody certifies a metric; they certify it for something. Consolidated gross margin is certified for board and external reporting. Services gross margin is certified for staffing decisions and services reviews, and explicitly not for the board deck. Put those two next to each other with the same lifecycle: approved flag and you've built a trap that looks like governance.

So I'd add one field to Peter's four, and keep the same descriptive-not-prescriptive discipline he argued for:

owners: [finance-team]
approved_by: [j.smith@acme]
approved_on: 2026-04-18
lifecycle: approved
certified_for: [board_reporting, external_reporting]   # the scope of the approval

A list of plain strings. Ossie doesn't define the vocabulary; the organization does, the same way it decides who may approve. What Ossie gains is that a consumer can tell the difference between "approved" and "approved for what you're about to use it for." An agent asked for gross margin in a board context picks the one certified for it. An agent asked for gross margin with no context finds three approved candidates with non-overlapping scopes and has a principled reason to ask which one instead of guessing. That second behavior is the one that survives the audit question Peter described.

Two smaller things in the same spirit:

• approved_on wants a sibling effective_from. Definitions change. Freight-out moves into product cost next fiscal year; the old definition was approved and still governs last year's numbers. Approval date says when the decision was made; effective date says what period it governs. Finance will ask for both.
• "Approved" and "certified" are not quite the same claim. Approved says the owner signed off on the definition. Certified says it's fit for a named use. Nitin's title asks for the second. Peter's lifecycle captures the first. Both are worth carrying, and certified_for is how they stay distinct.

One last ask, because it follows from the same logic. The approval workflow lives outside Ossie, and so does the fuller agreement behind it: the plain-words definition, what it may be compared with, who reconciles the variants. Today the only way to point at that from inside a model is a custom_extensions entry, which means every organization invents its own convention. ODCS solved this with authoritativeDefinitions: a native, optional pointer to wherever the governing definition lives. If the four-plus-one fields above land, a sibling pointer of that kind would let them stay small, because anything that doesn't fit in them has somewhere standard to go.

The principle I'd offer the thread: record the decision, record its scope, and leave the workflow to the organization. The first two travel with the document. The third never could.