feat(core-spec): add semantic_model.behavior with actions/effects

[zljie]

PR: feat(core-spec): add semantic_model.behavior with actions/effects (alias action_types)

What

This PR adds an optional, vendor-agnostic first-class behavior block to OSI Core:

• semantic_model.behavior
• behavior.actions (preferred) with legacy alias behavior.action_types
• action.effects for machine-readable impact annotations (what a behavior reads/writes/derives)

Why

Many agent-driven workflows require deterministic action planning and attribution:

• verify an action plan is executable (inputs are satisfiable; steps are consistent)
• explain “what changed/why” for state fields and master data mutations
• derive impacted scope for governance and impact analysis

Embedding behavior under custom_extensions works but is not easily discoverable/validatable by generic tooling. Promoting a standard first-class block improves interoperability while preserving extensibility.

Backwards compatibility

• semantic_model.behavior is optional (additive change).
• Tools may keep supporting legacy embedded behavior JSON under custom_extensions.
• Within behavior, actions is preferred; action_types remains a supported alias.

Validation

Local validation passed using validation/validate.py:

• examples/p2p_behavior_effects_minimal.yaml
• examples/tpcds_semantic_model.yaml

Files changed

• core-spec/spec.yaml
• core-spec/spec.md
• core-spec/osi-schema.json
• core-spec/behavior-layer.schema.json (new)
• core-spec/behavior-layer.md (new)
• examples/p2p_behavior_effects_minimal.yaml (new)
• examples/tpcds_semantic_model.yaml (version bump)

Example included

Minimal SAP P2P example:

• suppliers/block and suppliers/unblock actions
• effects impacting suppliers.status

[jbonofre]

Can you please clarify between behavior-layer.schema.json and osi-schema.json?

[jbonofre]

I'm a bit confused here: it seems we have two behavior type definition:

• in behavior-layer.schema.json with standalone schema
• in osi-schema.json inline as $defs/Behavior, $defs/BehaviorAction, $defs/BehaviorEffect, $defs/BehaviorRule

I see already some differences before the two definitions.

Why not having osi-schema.json reference behavior-layer.schema.json via $ref.

I guess that having two schemas that must kept in sync manually will drift.

[jbonofre]

impact_type is a string here, but an implicit enum in spec.yaml.