About

VeridataOps

Product and architecture notes for governed infrastructure evidence, native CMDB presentation, source connectors, review workflows, and SaaS security.

Product Login
Architecture Sidecar Ingestion Engine
Truth Model Review Before Commit
Source Model Packaged Evidence
Destination Native + Pluggable

North Star

Reviewed Evidence Into Operational Truth

1 Assume Any Source

Any system, export, API, spreadsheet, controller, scanner, or log platform may contain useful estate evidence for reconciliation.

2 Map Meaning

Users map source fields to understandable meanings; they should not need to know destination-specific object internals.

3 Infer Objects

The application expands semantic values into canonical estate objects, destination records, external evidence, relations, and dependencies.

4 Protect Truth

The first-party estate model becomes reviewed truth through authority rules, confidence, provenance, validation, preview/review, and controlled apply to selected destinations.

5 Treat Destinations As Pluggable

Destinations should be configured and extended the same way sources are: typed, capability-aware, licensed where needed, and exposed through UI and API controls.

6 Own The Presentation Layer

The product owns the visual and API presentation of estate truth; NetBox, plugins, data warehouses, and other systems are destinations rather than the only final view.

7 Full IT Estate

The model must cover endpoints, infrastructure, identity, software, licensing, contracts, monitoring, security, DNS/IPAM, ownership, and lifecycle.

8 API First

Every domain capability available in the Flask UI must be available through a documented JSON API, except browser/session-only flows.

9 Self-Contained Data Packs

Source packs own source-specific icons, fields, setup guidance, capabilities, semantic mappings, source rules, readiness, and adapter metadata.

10 Capability-Gated Extensibility

Source packs are the unit of extension and commercial distribution; locked capabilities stay visible but cannot be executed until the backend confirms entitlement.

11 Operate As An Ingestion Engine

The product runs as a sidecar ingestion engine with separate presentation and backend/runtime processes so long-running work does not block the UI.

Ingestion Pipeline

The system converts raw source records into reviewed estate truth, a first-party presentation layer, and selected destination sync.

evidence -> presentation -> destinations
  1. raw source record
  2. source adapter
  3. originating authority
  4. semantic values
  5. estate evidence
  6. object graph
  7. contract validation
  8. dependency resolution
  9. identity resolution
  10. authority policy
  11. preview/review or validated direct apply
  12. approved or pre-approved apply
  13. first-party estate presentation layer with provenance
  14. selected destination sync

Operational Workflow

  1. Install or enable data packs for the infrastructure, identity, cloud, network, and operations systems that hold useful evidence.
  2. Store credentials through the tenant UI or a connector, then sample source fields before mapping.
  3. Map fields to shared meanings such as manufacturer, hardware model, owner, IP address, software, license, contract, or security posture.
  4. Create jobs that combine one or more sources into one reviewed object graph.
  5. Run previews and review creates, updates, conflicts, skips, diffs, dependencies, and source evidence.
  6. Publish only approved changes to the native presentation layer and configured downstream destinations.

Data Pack Guidance

Source packs are the default way to package source-specific fields, rules, mappings, icons, and setup instructions.

Source Responsibility Expected Behavior
Packaging Ship a data pack with connection fields, an icon, capabilities, semantic mappings, source rules, child rules, and operator guidance.
Discovery Use sample records or an initial API request to expose source fields before classification and mapping.
Semantics Own source-specific aliases and emit meanings like device name, serial, owner, VLAN, installed application, license, or lifecycle state.
Safety Do not represent non-device evidence as fake devices. Route software, contracts, DNS, ACLs, and security evidence to plugin/external records or custom fields.

Documentation

The Markdown documents in docs/ are available here for quick product, architecture, and workflow reference.

docs/*.md

Guardrails

Do not leak destination internals into basic mapping

Expose semantic targets such as manufacturer, hardware model, owner, VLAN, license, and security posture instead of asking users to pick low-level object fields.

Do not model non-device evidence as fake devices

Applications, licenses, policies, contracts, vulnerabilities, and observations must become plugin/external evidence or proper first-class objects.

Resolve dependencies explicitly

Dependencies such as Manufacturer -> Device Type -> Device or VRF -> Prefix must be visible, ordered, and policy-controlled.

Preserve originating authority

Track where fields, objects, and relations came from when third-party systems remain the native source of truth.

Separate truth states

Distinguish observed truth, declared truth, approved truth, presented truth, and destination-applied truth.

Preview, review, or validated direct apply

Use preview/review for POC, development, and sensitive changes; production jobs may use validated direct apply with pre-approved commits.

Keep presentation responsive

Long-running discovery, data-pack sampling, preview, apply, and review preparation must run outside the presentation process.

New sources and destinations must plug into the same model

Adapters, data packs, and destination packs should emit capabilities and contracts so arbitrary systems can contribute or receive estate data without bespoke UI rules.

The suite owns the primary view

Do not require NetBox or another downstream tool to be the place users inspect estate truth; the product must expose first-class visual and API views.

Keep UI and API in parity

Settings, sources, data packs, jobs, reviews, runs, users, capability state, and operational status must be manageable through documented API endpoints as well as the Flask UI.

Enforce gates in the backend

Capability gates and authorization gates must be enforced by the backend/API; the frontend only reflects those states.

Expand estate domains deliberately

Near-term expansion should prioritize certificates, backup posture, and cloud cost, in that order.