Developer platform / Repository notes

Operational semantics.
With explicit boundaries.

Implementation notes from the IndusMesh platform specification. These documents describe the software contract and scope. The marketing page’s interactive examples run locally and do not call a control plane.

REST APIsTenant-scoped authorizationBounded execution

Application access

Use your configured control-plane origin and /dashboard/ to sign in. This standalone overview does not host the Go application, a live ontology workbench, industrial adapters or plant command endpoints.

Evidence and qualification

This platform reports implemented software validation. It does not establish new physical HIL qualification, a new 72-hour soak, or new Industrial GA admission.

Standards profile

The supplied repository identifies isa95.operations as its explicitly verified bounded round-trip profile. AAS, OPC UA information models and Sparkplug references are not additional ONTO-05 verified profiles.

Temporal context

as_of filters supported context. Current-row authorities do not reconstruct old revisions they did not retain; unsupported records are omitted.

Reasoning and commands

The reasoning engine modifies only an authorized in-memory projection. It does not mutate canonical authority stores or independently execute plant commands.

Source implementation notes

Expand a document to read the supplied repository’s detailed behavior, API paths and claim boundaries.

Runtime Semantic Integrity & Conformance
# Runtime Semantic Integrity & Conformance

ONTO-00 upgrades source-to-semantic resolution from definition-aware projection to runtime conformance enforcement.

The current response contract is `industrial.semantic.resolution/v2`, described by `contracts/industrial-semantic-resolution-v2.schema.json`. The ontology definition contract remains `industrial.semantic/v1`.

## Three-state conformance

Runtime conformance is deliberately not boolean:

- `valid` — every ontology constraint that applies to the resolved node or edge is established and passes;
- `incomplete` — the ontology requires a fact, relationship, unit or evidence reference that the available canonical context cannot establish;
- `invalid` — available canonical data contradicts an ontology constraint.

`invalid` always dominates `incomplete` in a node, edge, or projection summary.

## Property enforcement

Resolved semantic properties are now checked against the effective inherited property definition before the projection can be considered conformant.

Enforced constraints:

- declared datatype (`string`, `number`, `integer`, `boolean`, `date`, `datetime`, `duration`, `json`, `enum`, `uri`);
- enum membership;
- single versus multi-valued multiplicity;
- required properties;
- canonical units.

A required property that is not available is `incomplete`. A value of the wrong datatype or multiplicity is `invalid`.

### Unit semantics

ONTO-00 does not silently convert units. A property with a declared unit resolves its source unit from an explicit property metadata mapping first and then from governed authority unit fields where appropriate.

- same canonical unit: valid;
- source unit unavailable: incomplete (`unit_unresolved`);
- dimensionally incompatible unit: invalid (`unit_dimension_mismatch`);
- dimensionally compatible but different unit: invalid (`unit_conversion_required`), because a governed conversion must be explicit rather than silently changing the value;
- unequal unsupported/custom units: invalid (`unit_mismatch`).

Governed transformations and conversions belong to ONTO-01.

## Relationship enforcement

Resolved relationships are checked after deterministic endpoint mapping.

Required relationship semantics: every resolved instance matching a relationship's `from_types` must have at least one outgoing instance of that relationship. Missing context is reported as `incomplete`.

Cardinality limits:

| Cardinality | Max outgoing per `from` | Max incoming per `to` |
| --- | ---: | ---: |
| `one_to_one` | 1 | 1 |
| `one_to_many` | unlimited | 1 |
| `many_to_one` | 1 | unlimited |
| `many_to_many` | unlimited | unlimited |

All edges in a conflicting cardinality group are marked `invalid`; the affected endpoint instance is also marked invalid. The resolver does not arbitrarily choose a winning edge.

## Relationship evidence

When `evidence_required=true`, an emitted semantic edge must carry at least one supporting authority evidence reference.

ONTO-00 emits stable references to the canonical fact that established a relationship, for example:

- `authority:im://.../asset/...#facility_id`;
- `authority:im://.../measurement_point/...#asset_id`;
- `source_binding:<binding-id>`;
- `manufacturing_relationship:<relationship-id>`.

If a relationship can be resolved but no authority evidence reference can be established, the edge is `incomplete` with `relationship_evidence_unresolved`.

These references establish provenance to the canonical authority record. They do not claim documentary assurance or independent review; richer evidence semantics remain a later ontology/evidence integration concern.

## API surface

Each resolved node and edge now contains:

```json
{
  "conformance": {
    "version": "industrial.semantic.conformance/v1",
    "status": "invalid",
    "violations": [
      {
        "code": "datatype_mismatch",
        "status": "invalid",
        "path": "properties.rated_power",
        "source_authority": "asset",
        "source_field": "rated_power",
        "expected": "number",
        "actual": "150"
      }
    ]
  }
}
```

The top-level response contains a bounded summary of valid, incomplete and invalid nodes/edges and total violations.

## Product experience

The Semantic Graph source-resolution preview displays:

- overall conformance status;
- valid/incomplete/invalid node counts;
- valid/incomplete/invalid edge counts;
- violation count;
- per-node and per-edge conformance;
- relationship evidence-reference counts;
- precise runtime violation details.

## Qualification boundary

ONTO-00 validates semantic conformance of the data available to the source resolver. It does not infer missing facts, perform arbitrary mapping transformations, silently convert source values, validate all plant data outside the bounded source projection, or claim standards/HIL certification.
Executable Semantic Views & Query
# Executable Semantic Views & Query

ONTO-02 turns `IndustrialSemanticViewDefinition` from a compiled modeling artifact into a bounded runtime query surface over canonical industrial instances.

## Runtime endpoint

`POST /api/v1/industrial/semantic/graphs/{graphID}/versions/{versionID}/views/{viewKey}/query`

The caller supplies a tenant-owned `source_id`. The server resolves that source through the existing SEM-02/ONTO-00/ONTO-01 pipeline and executes the selected saved semantic view against the resolved instance graph.

## Enforcement boundary

The server always enforces the saved view's:

- root object types;
- reachable object-type closure;
- allowed relationship types;
- relationship direction;
- maximum traversal depth;
- result limit;
- property projection;
- saved typed filters; and
- evidence visibility policy.

Runtime filters can only narrow the view. They cannot introduce object types, properties, operators, traversal depth, or relationships outside the compiled view boundary.

The runtime grammar does not expose SQL, arbitrary scripts, arbitrary expressions, writes, or external network callbacks.

## Query semantics

Results are returned as deterministic **root-instance rows**. Each row contains the root semantic instance plus the bounded related nodes and edges reachable from it.

Filters are grouped by object type. For each filtered object type, at least one reachable instance in the row must satisfy all predicates for that type. This supports queries such as a Motor root constrained by properties of its related Measurement instances.

Typed filters support `eq`, `ne`, `gt`, `gte`, `lt`, `lte`, `in`, and `exists`. Ordered comparisons are restricted to number, integer, date, datetime, and duration properties. Filter values are validated against the declared semantic datatype before execution.

Filtering and aggregation occur against the full resolved semantic fact set **before projection**. This allows a view to filter or aggregate on a governed property without returning that property to the caller.

## Pagination

Rows are sorted by canonical root reference. Opaque cursors are bound to the graph checksum, view key, source ID, runtime filters, aggregates, traversal depth, conformance mode, and manufacturing-context choice. Replaying a cursor against a changed plan or graph checksum is rejected.

The cursor cannot move beyond the saved view's `result_limit`.

## Aggregates

The bounded runtime supports:

- `count`
- `sum`
- `avg`
- `min`
- `max`

Numeric aggregates require number/integer semantic properties. Aggregates are computed over distinct semantic instances in the bounded matching result set and are tenant scoped by the authenticated request.

## Historian enrichment

A query may request historical enrichment. Measurement nodes returned on the current semantic-view page are converted into governed historian selectors and passed to the existing DASH-04 historical query engine.

Historian enrichment inherits existing limits, unit conversion, quality filters, provenance, restatement handling, and tenant isolation. It is capped at 64 measurement series per semantic-view page.

## Runtime conformance

Each returned node and edge retains ONTO-00 conformance status. `require_conformant=true` prevents invalid instances from becoming roots or traversal targets. Incomplete instances remain distinguishable from contradictory/invalid instances.

## Operator UI

The Semantic Graph workspace now includes an **ONTO-02 Executable View** panel. Operators can:

- select a saved semantic view;
- execute it against the source ID already used for semantic resolution;
- choose a page size;
- exclude invalid instances;
- optionally include last-24-hour historian evidence; and
- follow deterministic next-page cursors.

The UI is only a client of the same server-enforced query boundary.


## ONTO-03 temporal execution

Executable views now accept an optional `as_of` timestamp and `require_fresh` policy. The server evaluates authority valid time, observation time, recorded/knowledge time, and governed mapping freshness before rows are returned. Cursor identity includes these temporal controls, so a cursor cannot be replayed against a different time boundary. Historian enrichment is clipped to the same `as_of` boundary.

The implementation is intentionally conservative: when a canonical store exposes only its current revision, a current record whose recorded/observation time is newer than `as_of` is excluded. IndusMesh does not fabricate an earlier revision that the authority did not retain.
Temporal Semantic Context & Evidence
# Temporal Semantic Context & Evidence

ONTO-03 makes time an explicit part of runtime semantic meaning without replacing existing canonical industrial authorities or inventing a second history database.

## Temporal fact model

Resolved nodes, properties, classifications, and relationships carry `industrial.semantic.temporal/v1` context:

- `fact_origin`: `observed`, `derived`, or `inferred`;
- `valid_from` / `valid_to` when an authority or governed mapping exposes business-valid time;
- `observed_at` when the source fact was observed;
- `recorded_at` when the current authority revision was recorded;
- `evaluated_at`, the semantic evaluation instant;
- `freshness`: `fresh`, `stale`, or `unknown`;
- optional governed `freshness_max_age`.

`valid_to` is an exclusive upper bound.

## Governed mapping time

A mapping rule may add a bounded `temporal` block:

```json
{
  "observed_at_field": "observed_at",
  "recorded_at_field": "recorded_at",
  "valid_from_field": "valid_from",
  "valid_to_field": "valid_to",
  "freshness_max_age": "15m"
}
```

The temporal fields are read only from the same canonical authority record already selected by the mapping rule. Arbitrary scripts or external callbacks are not allowed. `freshness_max_age` must be a positive Go duration such as `15m`, `2h`, or `24h`.

## Fact origin

- Direct authority-backed values are `observed`.
- Values changed by bounded mapping transformations are `derived`.
- Ontology classifications are `inferred` because they are semantic conclusions over authority facts.
- Canonical topology edges are `derived`.
- Manufacturing relationship records are `observed` and retain their authority valid-time window.

## Freshness and conformance

When a mapping declares `freshness_max_age`:

- observation age within the window => `fresh`;
- observation age outside the window => `stale`;
- unavailable observation time => `unknown`.

Stale or unknown governed freshness produces ONTO-00 `incomplete` conformance rather than `invalid`: the source value may be structurally valid but no longer sufficient to establish current operational truth.

Executable views can set `require_fresh=true`. Rows containing governed facts that are stale or whose required freshness cannot be established are excluded.

## `as_of` semantics

Both source resolution and executable semantic views accept optional `as_of`.

A fact is visible only when:

- it was not recorded after `as_of`;
- it was not observed after `as_of`;
- `valid_from` is absent or not later than `as_of`; and
- `valid_to` is absent or later than `as_of`.

This combines business-valid time and knowledge/observation time in a bounded runtime check.

### Conservative revision rule

Most canonical asset/facility/measurement/source-binding stores currently retain the current row plus `CreatedAt`/`UpdatedAt`, not a full bitemporal revision ledger. ONTO-03 therefore does not reconstruct a prior revision from a newer current row. If the current revision's `recorded_at`/`observed_at` is later than `as_of`, the resource is omitted.

Manufacturing objects and relationships already expose `ValidFrom`/`ValidTo`, so those windows are enforced directly.

## Historian alignment

Executable semantic views continue to use the existing governed historical query engine. When `as_of` is present, historian `to` is clipped to `as_of`; a historian `from` later than `as_of` is rejected.

This prevents the semantic answer from being evaluated in one temporal frame while telemetry evidence is fetched from a later frame.

## Contract versions

- source resolution: `industrial.semantic.resolution/v4`
- executable view response: `industrial.semantic.view.execution/v2`
- temporal context: `industrial.semantic.temporal/v1`

Earlier resolution/view schemas remain in the repository for compatibility/documentation.
Ontology Workbench & Guided Modeling
# Ontology Workbench & Guided Modeling

ONTO-04 turns the Industrial Semantic Graph designer into a guided ontology workbench while retaining the existing `industrial.semantic/v1` manifest as the only governed definition source.

## Design principles

- **No parallel ontology store.** Object types, properties, relationships, views, mappings, classification rules, and test cases are versioned in the semantic manifest and therefore participate in checksum, draft immutability, impact analysis, review, and promotion.
- **No runtime simulator.** Live preview and ontology tests execute the ONTO-03 resolver against authority-owned industrial records.
- **No arbitrary scripts.** Mapping transformations, classification predicates, and test assertions use bounded grammars.
- **JSON is an escape hatch, not the normal workflow.** Normal authoring uses guided forms; Advanced JSON remains for uncommon metadata and standards references.

## Workbench contract

`industrial.semantic.workbench/v1` is described by `contracts/industrial-semantic-workbench-v1.schema.json`.

The workbench descriptor exposes the current checksum, draft/editability state, semantic validation, and supported authoring catalogs for roles, authorities, data types, property semantics, cardinalities, mapping transforms, classification predicates, and ontology-test assertion kinds.

## API

```text
GET  /api/v1/industrial/semantic/graphs/{graphID}/versions/{versionID}/workbench
POST /api/v1/industrial/semantic/graphs/{graphID}/versions/{versionID}/workbench/preview
GET  /api/v1/industrial/semantic/graphs/{graphID}/versions/{versionID}/workbench/diff?base_version_id={versionID}

GET    /api/v1/industrial/semantic/graphs/{graphID}/versions/{versionID}/test-cases
GET    /api/v1/industrial/semantic/graphs/{graphID}/versions/{versionID}/test-cases/{testKey}
PUT    /api/v1/industrial/semantic/graphs/{graphID}/versions/{versionID}/test-cases/{testKey}
DELETE /api/v1/industrial/semantic/graphs/{graphID}/versions/{versionID}/test-cases/{testKey}
POST   /api/v1/industrial/semantic/graphs/{graphID}/versions/{versionID}/test-cases/{testKey}/run
```

Draft writes continue to use checksum-bound optimistic concurrency through `If-Match` when supplied and the store's mandatory expected-checksum update.

## Guided authoring

The Semantic Graph UI now provides structured editors for:

- object types and properties, including datatype, semantic type, canonical unit, enum values, required/multi-valued behavior, inheritance, authority, and evidence expectations;
- relationships, endpoint types, direction, cardinality, required state, inverse key, and evidence requirements;
- semantic views and traversal/result boundaries;
- governed source-to-property mappings, bounded transformations, unit conversion, temporal fields, and freshness policy;
- predicate-based classification rules;
- reusable runtime ontology tests.

## Live preview

Workbench preview first validates the selected manifest, then executes the existing semantic resolver against the requested source. Preview results therefore include ONTO-00 conformance, ONTO-01 mapping/classification provenance, and ONTO-03 temporal/freshness context.

The workbench does not synthesize source records or historical revisions.

## Visual diff

The workbench diff endpoint compares any two versions of the same graph using `DiffIndustrialSemanticManifests`. Results are checksum-bound and identify added, modified, removed, and breaking resources. Ontology test cases participate in this diff so qualification changes remain reviewable.

## Governed ontology tests

Test cases are optional manifest resources. Each test specifies a bounded source resolution request and up to 64 assertions. Supported assertions are:

- `node_type_present`
- `relationship_present`
- `property_equals`
- `conformance_status`
- `classification_status`
- `freshness_status`

Arbitrary scripts, SQL, callbacks, and network actions are not accepted.

A saved default `source_id` may be overridden at execution time so the same test definition can be reused across qualified source instances without editing the ontology definition.

## Completion criterion

A domain expert can create and edit ontology resources with guided controls, inspect validation before publication, preview the ontology against live authority-owned data, compare semantic versions visually, and save/run bounded regression tests without manually editing JSON for the normal workflow.
Standards & Reusable Domain Packs (ISA-95)
# Standards & Reusable Domain Packs (ISA-95)

ONTO-05 extends the governed Industrial Semantic Graph with versioned standard profiles, reusable domain packs, stable external identifiers, and checksum-bound definition interchange.

## Scope and claim boundary

The standards layer is a **definition-interchange and semantic mapping capability**. It does not turn a semantic reference into blanket conformance or certification for an external standard.

The repository currently carries one explicitly verified bounded round-trip profile:

- `isa95.operations` — ISA-95 / IEC 62264 manufacturing-operations vocabulary mapped to the existing NEXT-03 canonical manufacturing authority.

The round-trip qualification means that the normalized semantic meaning of this bounded profile survives **export → import → export** with the same SHA-256 meaning checksum. It does not claim complete IEC 62264 Parts 2–8 conformance, B2MML interoperability, standards-body certification, or compatibility with every MES implementation.

AAS, OPC UA information models and Sparkplug namespace references remain available as semantic references but are not marked as ONTO-05 verified round-trip profiles until separately mapped and qualified.

## Manifest resources

`industrial.semantic/v1` remains the canonical semantic manifest contract. ONTO-05 adds optional, backward-compatible resources:

- `standard_profiles[]`
- `domain_packs[]`
- `profile_key` on standard references

Standard profiles define a stable profile key, named external standard, version/profile description, absolute URI/URN namespace, and bounded scope.

Domain packs are versioned membership manifests that reference governed object types, relationship types, views, mappings, classifications and ontology tests already contained in the same semantic version.

Both resources are included in normalization, validation, manifest checksum, branch diff/impact, publication and immutability.

## Stable external identifiers

A standard reference may bind to a `profile_key`. When it does, ONTO-05 requires a non-empty stable `external_id`.

Profile-scoped external identifiers must be unique within the semantic manifest. Duplicate bindings are rejected during validation. Changes to object/property/relationship standard identity bindings are treated as breaking semantic changes by governance.

The existing IndusMesh `im://{account}/{authority}/{resource-kind}/{resource-id}` identity remains the canonical runtime instance identity. External identifiers are semantic interoperability identifiers, not replacement primary keys.

## Domain-pack exchange

Contract:

`industrial.semantic.domain-pack.exchange/v1`

Schema:

`contracts/industrial-semantic-domain-pack-exchange-v1.schema.json`

An exchange payload contains:

- pack membership and version;
- included standard profile definitions;
- selected object/relationship/view definitions;
- selected mapping/classification/test resources;
- optional graph-level standard references;
- `meaning_checksum_sha256`.

The meaning checksum is calculated over the normalized exchange with the checksum field cleared. Import validates that checksum before applying resources to a draft.

## APIs

Catalog:

- `GET /api/v1/industrial/semantic/domain-packs`
- `GET /api/v1/industrial/semantic/domain-packs/{packKey}`

Installed graph-version resources:

- `GET .../standard-profiles`
- `GET .../installed-domain-packs`
- `GET .../installed-domain-packs/{packKey}/export`
- `POST .../domain-packs/import`

Import requires an editable semantic draft and uses the existing checksum/ETag optimistic-concurrency path.

Conflict policies are bounded to:

- `reject` — fail if a resource key already exists;
- `replace` — explicitly replace the same stable resource keys, followed by full semantic validation.

There is no arbitrary import scripting.

## Built-in verified pack

`domain-packs/isa95-operations-core-v1.json`

Pack key:

`isa95.operations.core`

Profile key:

`isa95.operations`

The initial pack maps these canonical NEXT-03 manufacturing kinds:

- Equipment Class
- Process Segment
- Material Definition
- Production Request
- Production Schedule
- Production Response
- Production Performance

Each type carries a stable profile-scoped external identifier. Runtime instances remain in the canonical `industrial.manufacturing/v1` store.

## Operator experience

The Semantic Graph page includes an ONTO-05 panel that shows:

- installed standard profiles;
- installed reusable packs;
- available catalog packs;
- verified round-trip profile count;
- the exact meaning checksum;
- inspect/install/export actions.

The UI explicitly labels verification as bounded-profile round-trip evidence rather than generic standards certification.

## Qualification

ONTO-05 tests prove:

1. the built-in ISA-95 operations pack validates;
2. import into another semantic manifest succeeds;
3. export after import has the exact original meaning checksum;
4. the repository-carried JSON fixture matches the runtime catalog checksum;
5. duplicate profile-scoped external IDs are rejected;
6. `reject` and `replace` conflict policies behave deterministically;
7. stable external-ID changes are governance-breaking;
8. the public contract advertises only `isa95.operations` as a verified ONTO-05 round-trip profile.

Use `scripts/verify-onto-05.sh` for the focused repository-carried verifier.
Governed Reasoning & Deterministic Inference
# Governed Reasoning & Deterministic Inference

ONTO-06 extends the governed Industrial Semantic Graph with bounded, deterministic inference over the already-authorized semantic projection. It does not add a second authority store, arbitrary rule scripting, external callbacks, or an autonomous plant-write path.

## Reasoning contract

Contract:

`industrial.semantic.reasoning/v1`

Schema:

`contracts/industrial-semantic-reasoning-v1.schema.json`

The semantic resolution envelope advances to:

`industrial.semantic.resolution/v5`

Reasoning rules and the optional reasoning policy are first-class resources in the existing `industrial.semantic/v1` manifest, so they participate in normalization, checksum/versioning, branch governance, publication immutability, workbench editing, semantic diff and ontology qualification.

## Bounded rule grammar

A rule selects a `subject_type`, evaluates a bounded list of conditions, and emits one conclusion.

Supported condition kinds:

- `property` — typed predicate over a resolved semantic property;
- `relationship` — requires a governed relationship in a bounded direction and optional target type;
- `type` — requires an existing or previously inferred semantic type.

Supported conclusion kinds:

- `property` — derive a semantic property value;
- `type` — derive an additional semantic type.

Property predicates reuse the bounded semantic-filter operators (`eq`, `ne`, `gt`, `gte`, `lt`, `lte`, `in`, `exists`). There is no arbitrary code, network callback, shell execution or dynamic plugin invocation in the rule grammar.

## Deterministic bounded execution

Global hard limits are enforced for:

- number of reasoning rules;
- conditions per rule;
- inference rounds;
- total derived facts;
- applications per rule.

Rules are ordered deterministically by priority/key. Repeated evaluation of the same authorized projection and manifest yields the same derivation checksum.

Chaining is bounded. Facts derived in an earlier round may satisfy later rules, but execution stops at the configured round/fact ceilings and reports truncation when a ceiling is reached.

## Authority and conflict safety

Reasoning modifies only the in-memory semantic projection returned by resolution. It never mutates canonical facility, asset, manufacturing, measurement, historian, evidence or command authorities.

Observed/mapped authority facts take precedence. If a rule proposes a different value for an already-observed property, ONTO-06 preserves the observed fact and emits an inspectable `reasoning conflict` instead of overwriting it.

Derived property provenance is marked as `reasoning_rule`, fact origin is `inferred`, and carries the rule key, rule SHA-256, dependency IDs, evidence references, temporal context, explanation and derivation checksum.

## Explanation and dependency graph

Every inferred fact is attributable to the exact rule and exact dependencies that produced it. The reasoning result includes:

- derived facts;
- dependencies;
- conflicts;
- explanation graph nodes/edges;
- per-fact derivation checksums;
- aggregate derivation checksum;
- rounds, rules evaluated/applied and truncation state.

Dependencies may reference semantic properties, types and relationships already present in the authorized projection. Evidence references are propagated where available.

## Permission and tenant boundary

Reasoning evaluation runs only after normal graph/version authorization and uses the caller's tenant-scoped canonical stores. Rule CRUD is Developer-authorized. Evaluation is Viewer-authorized because it is a read-only projection operation.

Rules cannot query another tenant or bypass the source-resolution authorization boundary. The ONTO-06 qualification includes explicit cross-tenant denial coverage.

## Production publication policy

Contract:

`industrial.semantic.publication/v1`

Development graphs retain direct draft publication where existing policy permits it.

For graphs marked as production (`environment`, `deployment_environment`, or `stage` metadata), a bootstrap publication is allowed when no current version exists. After bootstrap, direct publication is rejected and subsequent semantic changes require the existing governed branch flow with impact analysis, independent review and promotion.

The policy is exposed at:

`GET /api/v1/industrial/semantic/publication-policy`

This closes the ambiguity between governed branch promotion and ordinary direct publication for production semantic definitions.

## APIs

Contract/policy:

- `GET /api/v1/industrial/semantic/reasoning/contract`
- `GET /api/v1/industrial/semantic/publication-policy`

Graph/version reasoning resources:

- `GET .../reasoning-rules`
- `GET .../reasoning-rules/{ruleKey}`
- `PUT .../reasoning-rules/{ruleKey}`
- `DELETE .../reasoning-rules/{ruleKey}`
- `POST .../reasoning/evaluate`

Evaluation reuses ONTO-03 temporal `as_of` semantics and the same topology/manufacturing/source-resolution options. No separate reasoning instance store is introduced.

## Ontology Workbench

ONTO-04 is extended with guided reasoning-rule authoring for:

- subject type;
- match mode and priority;
- bounded conditions;
- conclusion;
- application ceiling;
- enable/disable state.

The Semantic Graph workspace also provides an **Evaluate Reasoning** action and displays inferred facts, dependencies/conflicts, truncation state and derivation checksum.

Ontology test cases can assert `reasoning_fact_present`, making expected inferred facts reusable qualification resources that version with the ontology.

## Qualification boundary

Repository-carried ONTO-06 tests prove:

1. multi-round bounded inference;
2. reproducible derivation checksums;
3. dependency/explanation graph generation;
4. observed facts are not overwritten;
5. unsupported/script-like grammar is rejected;
6. 5,000-node reasoning remains capped by the configured derived-fact ceiling;
7. rule CRUD and evaluation remain tenant isolated;
8. production direct publication is rejected after bootstrap;
9. reasoning changes are governance-breaking semantic changes;
10. public contracts advertise reasoning and production publication policy.

This wave does **not** claim unrestricted OWL reasoning, SHACL rules, probabilistic/ML inference, physical HIL requalification, independent standards certification, or a new GA release admission.