# Ontology Service Placement and Near-Term Use Cases

Status: planning note
Date: 2026-06-18
Scope: architecture direction for NodeDC ontology work

## Current State

Current research workspace:

```text
/Users/dcconstructions/Downloads/mnt/NODEDC_ONTOLOGY
```

This workspace is a temporary documentation/write area for ontology design, evidence ledgers, guardrails, and open questions.

It should not be treated as the final production home.

Do not move it while the active ChatGPT `NodeDC Ontology Write` app points at this path. Moving it now would break the connector.

## Target Home

The ontology belongs in the platform layer, not as a random folder in `mnt`.

Recommended future home:

```text
/Users/dcconstructions/Downloads/mnt/NODEDC/platform/services/ontology-core
```

Alternative names:

```text
platform/services/ontology-registry
platform/services/context-registry
```

Recommended name for now:

```text
ontology-core
```

Reason:

- It is a platform service, not a feature of only HUB, OPS, or ENGINE.
- It should live near:
  - `services/notification-core`
  - `services/ai-workspace-assistant`
  - `services/ai-workspace-hub`
- It should not own HUB/OPS/ENGINE domain data directly.
- It should own canonical cross-app meaning, aliases, relations, routing context, and guardrails.

## What Ontology Core Should Own

Ontology Core should own:

- canonical entity catalog;
- relation catalog;
- alias registry;
- evidence ledger;
- guardrails / forbidden conflations;
- cross-surface context mapping;
- future API for entity/relation resolution;
- future API for assistant/tool routing context.

Ontology Core should not own:

- Launcher users/clients/groups/access data;
- Plane/OPS cards/projects/workspaces/comments;
- Engine workflows/nodes/runtime events;
- Authentik identity/session data;
- Notification deliveries/read-state;
- actual source-code edits.

Domain data stays with the owning service. Ontology Core describes and connects meaning across services.

## Near-Term Product Use Case

The first practical value is cross-application assistant routing.

### OPS to ENGINE

Example:

```text
User is in OPS and asks Assistant:
"Replace the workflow for this project/card with another Engine workflow and then continue coding."
```

Expected future behavior:

1. Assistant knows current OPS surface context:
   - workspace;
   - project;
   - card;
   - selected assistant/project context.
2. Ontology resolves that OPS context to relevant Engine application boundary / workflow context.
3. Assistant can ask the correct Engine-side tool/action to inspect or switch workflow.
4. Engine remains owner of workflow internals.
5. OPS remains owner of card/project/task context.
6. The action is auditable and bounded by user permissions.

Ontology requirement:

```text
ops.card / ops.project / ops.workspace
  can relate to
engine.application_boundary / engine.workflow_l1 / engine.workflow_l2
  through explicit relation and permission context,
not by hardcoded UI assumptions.
```

### ENGINE to OPS

Example:

```text
User is in ENGINE and asks Assistant:
"Create OPS tasks for this workflow issue / describe next implementation steps in the right project."
```

Expected future behavior:

1. Assistant knows current Engine surface context:
   - workflow;
   - node;
   - application boundary;
   - selected assistant/project context.
2. Ontology resolves the target OPS workspace/project/card destination.
3. Assistant can create or update OPS cards through scoped OPS Gateway operations.
4. User should not have to manually switch assistant project if target can be resolved by name/context.

Ontology requirement:

```text
engine.workflow_l1 / engine.node_l1 / engine.application_boundary
  can relate to
ops.workspace / ops.project / ops.card
  through explicit routing relations and aliases.
```

## Why This Matters

Without ontology:

- Assistant context is surface-local.
- OPS assistant may not know the correct Engine workflow target.
- Engine assistant may not know the correct OPS project/card destination.
- Users must manually switch projects/surfaces.
- Workflows become hardcoded by UI glue and fragile assumptions.

With ontology:

- Assistant can resolve user intent across HUB, OPS, ENGINE, and platform services.
- Names, aliases, and relations can be normalized.
- Cross-app actions can be permissioned, audited, and routed.
- Future automation can target stable meanings instead of brittle file/UI paths.

## Design Guardrails

Ontology must stay flexible:

- Core ontology should stay small and stable.
- Task-specific entities can be added later per domain.
- Do not force every future use case into the first core catalog.
- Use statuses:
  - `source-confirmed`
  - `source-evidenced/context-derived`
  - `product-required`
  - `future concept`
  - `tech debt / non-canonical`
- Dirty but working implementations should be marked as tech debt, not silently promoted into canonical product truth.

## Known Dirty Areas To Track

### Engine-side OPS / tender-agent / Agent Monitor

Status:

```text
tech debt / non-canonical
```

Do not use it as OPS product truth.

Future direction:

```text
automation control surface / UI constructor / automation work views
```

Automation nodes should emit structured data into a separate work/control layer rather than keeping heavy custom OPS-like UI inside ENGINE.

Clarification:

- `OPS product` means the separate operational system / Tasker surface with workspaces, projects, cards, statuses, labels, comments, and assignment.
- `Engine-side OPS / tender-agent / Agent Monitor` means the old custom workflow/UI implementation inside ENGINE. It is a working prototype/legacy slice, not the canonical OPS product model.
- Do not let the ontology merge these two meanings under one root.
- Treat the Engine-side tender UI as evidence for future interface needs, not as the final architecture.

### Future Interface / Automation UI Layer

Status:

```text
future concept / product-required soon
```

Strategic direction:

- ENGINE should remain a workflow/development environment.
- New heavy custom product interfaces should not be hardcoded inside ENGINE.
- Automation/workflow nodes should be able to emit structured data for a separate interface/control layer.
- A future platform service or app should own user-facing automation work views, dashboards, cards, maps, analytics panels, and other generated/custom UI surfaces.
- Assistants are expected to help assemble these interfaces from ontology-backed domain meanings and UI rules.

Possible future names:

```text
platform/services/interface-core
platform/services/automation-ui
platform/services/workview-core
platform/services/ui-workbench
```

No final name is selected yet.

The ontology must be ready to describe:

- domain entities and their aliases;
- workflow node outputs;
- UI view definitions;
- widget/control types;
- dashboard/work-view composition;
- source application and permission context;
- relation from OPS card/project or ENGINE workflow/node to the generated UI surface.

Near-term implication:

```text
Do not canonize the current tender-agent / Agent Monitor UI embedded in ENGINE.
Use it as a learning sample for what the future interface layer must support.
```

### Domain Ontology Expansion

Core ontology should stay compact, but it must leave a clean path for domain ontologies.

Expected domain families already visible from product direction:

- tenders / procurement;
- ecology;
- transport analytics;
- robotics / Helius-style analysis;
- business processes;
- ERP-like operational domains;
- future client-specific domains.

These domains should extend the core catalog rather than polluting the core roots.

Recommended shape:

```text
core ontology
  -> platform/service/application/surface/user/card/workflow basics
domain ontology
  -> domain-specific entities, fields, relations, UI views, and automation outputs
```

### Assistant Project / Surface Selection

Current concern:

```text
Assistant can be attached to one project/context at a time, forcing manual switching.
```

Ontology should support later resolution by:

- entity name;
- aliases;
- current surface;
- user permissions;
- project/workflow/card relation;
- explicit target override from the user.

This is a core near-term reason for building the ontology.

### MCP / Codex Config Routing

Current OPS Gateway already has a rough setup/config route:

```text
AI Workspace / Codex config
  -> token-scoped MCP grant
  -> OPS Gateway
  -> Tasker internal adapter
```

Do not refactor this immediately.

Ontology can later improve this by resolving the correct target context before issuing or selecting grants:

- owner/user identity;
- active surface;
- OPS workspace/project/card;
- ENGINE application/workflow/node;
- explicit user target;
- aliases and product names;
- permitted tool/action set.

This keeps the current working MCP path while creating a path toward less manual config and safer assistant routing.

## Migration Plan

Short term:

1. Keep writing research docs in `NODEDC_ONTOLOGY`.
2. Finish evidence ledgers for HUB / OPS / OPS Gateway / ENGINE.
3. Create consolidated:
   - `CANONICAL_ENTITY_CATALOG.md`
   - `RELATION_CATALOG.md`
   - `EVIDENCE_LEDGER.md`
   - `GUARDRAILS.md`
   - `OPEN_QUESTIONS.md`

Medium term:

1. Create `platform/services/ontology-core`.
2. Move accepted docs from `NODEDC_ONTOLOGY/ontology` into the service docs.
3. Reconnect ChatGPT write app to the final path.
4. Decide whether the service starts as docs-only, JSON registry, or API + DB.

Long term:

1. Add machine-readable catalog format.
2. Add resolver APIs for Assistant / OPS Gateway / Engine tools.
3. Add relation/evidence versioning.
4. Add permissions-aware context resolution.
