# Evidence Ledger — ENGINE Dirty Boundary P1

Status: source-backed tech-debt boundary note
Baseline: Compact Canonical Entity Catalog v0.3.1
Date: 2026-06-18
Scope: ENGINE-side OpsLayer / tender-agent / Agent Monitor boundary

Source root:

```text
/Users/dcconstructions/Downloads/mnt/NODEDC/NODEDC_ENGINE_INFRA/nodedc-source
```

Restrictions observed:

- Source inspection only.
- No runtime/data/storage/env/secrets/logs/dumps.
- No source code edits.
- No build/test/install/docker execution.

## Summary

This pass confirms an important ontology boundary:

```text
OPS product
  != OPS Gateway
  != ENGINE-side OpsLayer / tender-agent / Agent Monitor
```

The ENGINE repository contains a substantial embedded `OpsLayer` around L2 execution workflows, tender search/review, monitor profiles, agent runs, trace events, and Agent Monitor UI nodes.

This code is working product/legacy infrastructure, but it must be treated as:

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

It should not be promoted into canonical OPS product truth and should not define the final automation UI architecture.

## Boundary Evidence

| Boundary ID | Canonical treatment | Evidence status | Evidence file:line | Evidence explanation | Notes |
| --- | --- | --- | --- | --- | --- |
| `engine.tech_debt.ops_layer` | Engine-side legacy OpsLayer | source-confirmed tech debt | `server/index.js:25`, `server/index.js:333`, `server/routes/ops.js:1-34`, `server/routes/ops.js:6412-11855` | ENGINE imports `opsRouter` and mounts it at `/api/ops`; `routes/ops.js` implements a large set of run/result/tender/AI review/monitor endpoints. | This is not the separate OPS product / Tasker model. |
| `engine.tech_debt.ops_agent_instance` | Legacy Engine agent instance | source-confirmed tech debt | `server/ops/migrations/0001_init_opslayer.sql:89-137`, `src/store.ts:444-480`, `src/utils/opsApi.ts:759-855` | OpsLayer has `agents`, `agent_instances`, `agent_runs`; frontend prevents copied L2 nodes from inheriting `opsAgentInstanceId`; API can start/stop agent instances and record runs. | Do not merge with OPS Gateway `agent.identity`. |
| `engine.tech_debt.agent_monitor_node` | Agent Monitor canvas node | source-confirmed tech debt | `src/nodes/AgentMonitorNode.tsx:10-14`, `src/nodes/AgentMonitorNode.tsx:21-38`, `src/driveinspector/nodes/AgentMonitor.definition.ts:1-13` | ENGINE has a visible `agentMonitor` React Flow node and inspector definition that binds monitor profiles/agents through `opsApi`. | This is current UI embedding, not final interface layer. |
| `engine.tech_debt.monitor_profile` | Engine-side monitor profile | source-confirmed tech debt | `server/ops/migrations/0001_init_opslayer.sql:240-299`, `src/utils/opsApi.ts:260-360`, `src/utils/opsApi.ts:460-520` | OpsLayer stores monitor profiles, profile assignments, bound agent instances, execution cores, and monitor nodes; frontend can list/create/update/bind profiles and save monitor layouts. | Useful evidence for future work-view requirements. |
| `engine.tech_debt.tender_domain_ui` | Tender-specific embedded UI/domain slice | source-confirmed tech debt | Engine internal monitor implementation | ENGINE includes Kontur tender URLs, tender categories/electronic places, tender search settings, and a large Agent Monitor panel. | Treat as procurement/tender domain evidence, not core ontology. |
| `engine.tech_debt.tender_storage` | Tender storage inside Engine OpsLayer | source-confirmed tech debt | `server/ops/migrations/0001_init_opslayer.sql:210-239`, `server/ops/migrations/0006_tender_dedup_registry.sql:1-17`, `server/ops/migrations/0007_tender_details.sql:1-24`, `server/ops/migrations/0008_tender_documents.sql:1-37` | OpsLayer stores tender results, dedup registry, details, and downloaded documents. | Do not confuse with future domain ontology persistence. |
| `engine.tech_debt.tender_ai_review` | Tender AI review workflow state | source-confirmed tech debt | Engine internal monitor implementation | OpsLayer stores AI review tasks/latest state; UI has default manual AI criteria/response format; API enqueues/retries review tasks. | Useful sample for domain-specific assistant review flows. |
| `engine.tech_debt.ops_tabs_control` | Engine inspector ops control | source-confirmed tech debt | `src/driveinspector/ControlRegistry.tsx:27-50` | Drive inspector registers `opsTabs` control. | Another marker that Ops UI is embedded in ENGINE editor controls. |
| `future.interface_layer` | Future platform UI/work-view layer | product-required / source-informed | Engine internal monitor implementation; `src/utils/opsApi.ts:460-520`, `server/ops/migrations/0001_init_opslayer.sql:240-299` | Current monitor panel/layout/profile code shows the kind of configurable work views the future interface layer must support. | Future home should be separate platform service/app, not Engine core. |

## Route / Surface Evidence

| Surface | Evidence status | Evidence file:line | Evidence explanation |
| --- | --- | --- | --- |
| `/api/ops` is mounted inside ENGINE server | source-confirmed | `server/index.js:25`, `server/index.js:333` | ENGINE server imports and mounts `opsRouter`. |
| Ops router owns runs/results/tender/AI review/monitor APIs | source-confirmed | `server/routes/ops.js:6412-11855` | Router exposes health, runs, tender results/details/docs, AI review, trace, monitor profiles/layout/admin, agent instance start/stop, actions, contour limits/search. |
| Agent Monitor is an ENGINE canvas node | source-confirmed | `src/nodes/AgentMonitorNode.tsx:10-14`, `src/nodes/AgentMonitorNode.tsx:73-170` | Node type is `agentMonitor`; UI opens monitor through an L2 execution event. |
| Agent Monitor panel directly consumes Ops APIs | source-confirmed | Engine internal monitor implementation | Panel imports many Ops API functions for tender details, AI review, layout, runs, trace, start/stop, take-in-work. |
| Engine graph copy logic special-cases Ops bindings | source-confirmed | `src/store.ts:444-480` | Copied L2 nodes clear `opsAgentInstanceId`; copied `agentMonitor` nodes clear monitor profile/binding fields. |

## Guardrails Confirmed

```text
Do not use ENGINE server/routes/ops.js as OPS product truth.
Do not use ENGINE OpsLayer agent_instances as OPS Gateway agent.identity.
Do not use Agent Monitor as the final automation UI model.
Do not put future custom product UI directly into ENGINE core.
Do not collapse tender/procurement domain concepts into core ontology roots.
```

Canonical separation:

```text
ops.*
  = product OPS / Tasker / operational work system

agent.*
  = OPS Gateway execution identity, token, grant, scope, tool boundary

engine.tech_debt.*
  = current ENGINE-embedded OpsLayer / tender-agent / Agent Monitor legacy slice

future.interface_layer.*
  = future platform UI/work-view/configurator surface, still not implemented
```

## Product / Architecture Notes

### Why this matters

The current Engine-side tender/Agent Monitor implementation proves the need for an ontology-backed interface layer:

- users need domain-specific work views;
- workflows need to emit structured data into user-facing controls;
- assistants will likely compose or modify these views;
- tender/procurement is only the first domain slice;
- future slices may include ecology, transport, robotics/Helius, ERP/business processes, and client-specific domains.

But the current implementation should remain a learning sample and migration source, not the target architecture.

### Future target

Recommended direction:

```text
ENGINE
  owns workflow/node execution and development environment

future interface layer
  owns configurable work views, dashboards, maps, analytics, forms, and domain UI composition

Ontology Core
  resolves meanings, relations, aliases, domain schemas, and routing context
```

### Migration posture

Do not migrate or refactor this now.

Near-term treatment:

- document the boundary;
- avoid using these entities as canonical roots;
- use them as source-backed evidence for future interface/work-view requirements;
- preserve current working behavior until a real interface layer exists.

## Open Questions / Follow-up

1. Later ENGINE pass should separately document canonical workflow L1/L2 entities without mixing in OpsLayer.
2. Future interface-layer RFC should decide whether views/widgets/surfaces are core ontology entities or platform-service entities with ontology references.
3. Tender/procurement should become a domain ontology package, not a core ontology root.
4. Decide whether Engine-side OpsLayer data gets migrated, archived, or only bridged when the future interface layer exists.
