Operational Warehouse

A persistent, governed model of the enterprise.

Represent what exists, how it relates, what changed, what evidence supports a conclusion, and who is authorized to act—without pretending uncertainty has disappeared.

Persistent context
Entities + RelationshipsWhat exists and how it connects
State + HistoryWhat is true now and what changed
Evidence + ControlWhat supports the model and who may act
Persistent operational contextEvidence, history, and authority stay connected.

What persists

Organizational context that survives the session.

An Operational Warehouse is not one database pattern. Analytics stores, retrieval systems, graphs, document indexes, and operational services may all contribute. The durable responsibility is the governed combination of identity, time, evidence, policy, authority, action, and outcome.

Entities

  • Customers
  • People
  • Projects
  • Systems
  • Contracts
  • Assets

Relationships

  • Ownership
  • Dependencies
  • Membership
  • Approval
  • Lineage

State

  • Current values
  • Observed conditions
  • Desired state

History

  • Prior state
  • Changes
  • Decisions
  • Outcomes

Evidence

  • Sources
  • Provenance
  • Authority
  • Recency
  • Conflict

Control

  • Policy
  • Permissions
  • Business authority
  • Registered actions

Disagreement belongs in the model

Reality rarely agrees with itself.

Useful intelligence must be able to preserve contradictory observations, distinguish their scope and time, and say that a conclusion is not yet established.

ProductionPermissionSet = ACTIVE
GitPermissionSet = REMOVED
Work recordIntent = REMOVE
PolicyProduction changes require approval

Evidence becomes context

Isolated facts become operational meaning through a traceable chain.

Evidence is useful when the system can connect it to identity, relationships, state, policy, decisions, and the resulting outcomes.

Evidence-to-outcome lineage
  1. 01 / SourceSystem observation
  2. 02 / EvidenceProvenance retained
  3. 03 / EntityIdentified thing
  4. 04 / RelationshipMeaning in context
  5. 05 / StateCurrent + historical
  6. 06 / PolicyRule that applies
  7. 07 / DecisionAuthority evaluated
  8. 08 / OutcomeNew evidence recorded

Outcome returns to the warehouse as new evidence ↺

Illustrative release trace

Follow a consequential state back to evidence.

This public example is illustrative fixture data. It demonstrates the shape of governed context; it is not a live integration or customer record.

  1. RequirementEncrypt release artifact at restREQ-118 · approved revision 3
  2. Repository changeCommit a61fImplements artifact encryption
  3. Target environmentProductionEnvironment class: regulated
  4. Validation resultPassedV-184 · evidence captured
  5. Policy & approverPROD-04 · release ownerApproval is still required
  6. OutcomeBlocked pending approvalEvidence is sufficient; authority is not

Architectural responsibility

Different patterns solve different parts of the problem.

The Operational Warehouse is not a claim that warehouses, RAG, graphs, or vector databases are obsolete. It defines the broader persistent responsibility Verimir needs around them.

PatternPrimary strengthDoes not alone establish
Data warehouseAnalytics and structured historical analysisAuthority and complete operational context
RAGRetrieval of relevant source materialDurable operating state
Knowledge graphRelationships and semanticsComplete governance and controlled action
Vector databaseSemantic similarityEnterprise authority or temporal truth
Operational WarehousePersistent governed operational contextIt composes these capabilities; it does not replace each underlying technology.

The warehouse persists enterprise context. The Delivery Landscape applies that context to how the enterprise changes itself.

See the model applied to Delivery →

A useful first step

Choose an operating fact that is hard to establish today.

Bring the systems and evidence around it. We’ll identify the smallest useful Operational Warehouse starting point.

Talk to us