Discussion: How do we expect OSI to be used

[willpugh]

I'm wondering how we expect OSI to be use. As we move forward, I think that it affects how we reason about and rank solutions.

I see two different approaches that are implicit in some of the discussions I've seen and proposals:

1. OSI is an interchange format. Mainly used to help with conversions, and provide one place to consolidate models from different tools, but does not specify its own semantics or execution model. Vendors can have radically different expression languages, so extension is easy, but ensuring everything acts the same is hard.
2. OSI is a standard like SQL. In this approach, there are semantics, expression language, etc. Vendors are expected to implement the standard, and for the most part, one expression should work across compliant vendors. Vendor extensions can come in new functions and metadata, but semantics MUST comply with the standard.

Clearly approach 1 is easier as a standards body to implement, however, from the meeting a week ago, I got the impression that we think approach 2 is more valuable.

Do folks generally agree with that? or is this contentious?

I bring this up, because there are already things in the proposal that seem to tie us to 1. For example the dialects part of an expression:

expression:
    dialects:
      - dialect: ANSI_SQL
        expression: ss_sold_date_sk

The assertion behind adding this property is:

• It is common enough for expressions to differ by provider, that we should make the concept a first class citizen at the lowest level.
• It is common enough for expressions to have multiple implementations across providers that we should support this directly.

If we were to solve handling vendor extensions with the assumption that we are doing 2, then I would expect an approach that has vendor at the file level and allows for composition so the standards compliant behaviour can be shared.

Does anyone have thoughts on this?
My take is that 2 is a better approach, even though it has a higher amount of work to get right.

[dmariani]

My take is that we should strive for 2, because delivering a language standard would kill two birds with one stone: it can serve as an interchange format and a standard language. Why not strive for both?

[srcolinas]

Are there any progress on this topic? I was looking for a true standard to define the spec of a semantic model for a tool I am working on.

[QMalcolm]

Hi @srcolinas there has been a fair bit of discussion on this. We actually just published the project roadmap yesterday 🎉 Under the Metric Semantics & Core Semantic Model you'll find that one of the deliverables is Standard metrics specification language. There is currently a proposal document being worked on can be found here: https://docs.google.com/document/d/1Jn98kHWsnbvo1MycQBAnWirGTwRmw-DWaen7coNCYWA/edit?usp=sharing

It's less apparent than we'd like because we've been figuring out the proper process and tooling so people can find 😞 We are working to fix that though.

[magerdaniel]

I clearly support option 1. Option 2 is an utopie in my eyes

[MarioDeFelipe]

I tested this: One generated SAP ontology into two major agent platforms (Palantir and Microsoft Fabric), element by element, what each platform actually stored. Results: across five categories — identity, cardinality, actions, provenance, field-level synonyms — no two platforms broke the model the same way. The worst losses were silent: accepted with a success code, discarded without a word.

That experience reads directly onto the interchange-vs-standard question. Interchange without mandated semantics doesn't remove the N×M translation problem — it relocates it inside the standard: if every producer/consumer pair can interpret constructs differently, dialects become N×M reborn with better branding.

A middle position that would have saved us real losses: a small core with mandated behavior (identity, cardinality, constraints — the things agents act on), with dialect freedom reserved for expression syntax rather than construct semantics. Happy to share the anonymized loss table if it's useful to the discussion.

[willpugh]

We're been working on some defined semantics in the expression language group. I've got a PR for the current ones out, with an MD file that defines a slim set of semantics: #246

Would love any feedback. Particularly, if there are some of the inconsistencies you saw and whether we cover places in the spec that would address them.

The approach is not to get everything on the first rev, but get something in that is foundational and build on top of it.

[MarioDeFelipe]

Thank you for your comments Will. I have read the full document. Beautiful, and I have strong support for both the content and for the foundational-first approach.
You asked whether the inconsistencies we measured are covered; here I go:

It is covered, and good looking: The five user-visible semantics — especially Semantic 5 (typed error, never a plausible-but-wrong number) and Semantic 1's NULL-bucketing of unmatched fact rows — address the query-time family of what we saw in the field. The NULL determinism work (5.1 ordering defaults, 6.11 empty/NULL aggregate behaviour, NULL-safe stitch merges) pins down the places where two engines we tested with SAP quietly disagree today. Composite keys as first-class citizens in relationships (from_columns/to_columns, unique_keys) covers the compound-identity shape that ERP-class models live on — our four-part keys map onto the inference described in 6.4's is described cleanly.

The gap I see: The worst losses were not query-time — they were at transport-time: When I tested with Microsoft Fabric IQ, the platform accepted parts of the SAP semantic model with a success response but then silently discarded them. We only caught it by re-reading what was stored.

We published a generated SAP ontology into Fabric IQ's ontology item, and the API answered with success codes. Then, because we had a rule is to re-read everything we write — a getDefinition round-trip — we fetched back what Fabric had actually stored and diffed it against what we sent. No error, no warning, no partial-success flag — accepted with a 200, but then gone.

And this is the worst single loss: not because synonyms were lost — every platform loses something — but because nothing told us. If we have a schema rejection, we can handle it in a pipeline; but a silent drop we only catch if we are disciplined enough to read back and compare. And the payload matters for agents specifically: property-level synonyms are the alternative names that let an agent map a human question ("who's the client on this order?") to the right field. We can't risk an agent grounding on the stored model that doesn't know the synonyms ever existed.

So a permissive parser that ignores fields it doesn't model instead of rejecting them is to be avoided, and the PR comment deliberately claims only the observed behavior. For contrast, when we tested Palantir Foundry, the behaviour was different.

So my proposal is a conformance rule that implementations must represent, reject, or explicitly report a construct — and never accept-and-drop.

Now, two field notes from the SAP side:

1. Sentinel values vs. NULL. In SAP-sourced data, "missing" is usually not NULL — it's an initial value ('', '0000000000', '00000000'). Semantic 1's NULL bucket won't catch those, worth a future hook.
2. Declared cardinality, when it lands. 6.4's inference: world sources like SAP always know their cardinality — associations declare it, and especially in CSN. When the deferred declared-cardinality/RI proposal comes, two requests from the emitter side: keep declaration cheap (we declare, we never infer), and make declared-vs-inferred disagreement a typed error rather than silent trust of either side.

One clarifying question: the ontology layer's requires/derived_by fields also carry ANSI-SQL expressions. Is the intent that Ossie_SQL_2026 plus these evaluation semantics govern those expressions too, or does the ontology layer get its own semantics pass? Asking because if we are to build a CSN (SAP model language) → Ossie converter that emits closed-world constraints into requires, we'd like to target whichever contract will govern them.