Data AffectIT Consulting · Data Governance
Data Affect / Recova
A Data Affect research preview · Active R&D

Recova.

Enterprise Records Management + Data Privacy Governance Platform

A reusable, version-controlled information-governance architecture integrating the records lifecycle, privacy obligations, policy evaluation, workflow execution, provenance, and auditability.1

Explore the architecture →Ask about Recova
ONE INFORMATION ASSET · COMPETING OBLIGATIONS PRIVACYDeletion request RECORDSRetention schedule PRESERVATIONLegal hold CONTEXTException · rule version EVALUATED TOGETHER Conflict-resolution engine GOVERNED ACTION RETAIN DELETE PRESERVE RESTRICT ANONYMIZE DEFER ESCALATE FOR REVIEW DECISION HISTORY · EVIDENCE LEDGER
FIG. 4Recova evaluates competing records and privacy requirements together, rather than in separate applications. Schematic, for illustration.
§1The problem

Two related disciplines, usually kept apart.

Records Management and Data Privacy are closely related, but they are often implemented through separate policies, repositories, workflows, and applications. Records Management determines how information is classified, retained, preserved, placed on hold, and disposed. Privacy programs determine how personal information is classified, which rights and restrictions apply, and how individual requests are handled.

The difficulty is that the same information can be subject to both at once. A consumer may request deletion of personal information that the organization must also retain under a records schedule, litigation hold, investigation, contractual commitment, or statutory requirement.

“The question is not simply whether software can delete data or calculate a retention period, but whether it can determine the correct action—and preserve a reproducible explanation of how it was reached.”— Recova, core operating problem
§2Governed outcomes

Not “retain wins” or “privacy wins”, but a scoped, explainable decision.

Recova is designed to evaluate multiple factors together:

  • record classification and retention requirements
  • applicable privacy law and rule version
  • consumer privacy rights
  • legal holds and preservation requirements
  • data category and processing purpose
  • exceptions and organizational policies
  • the current lifecycle state of the information

From these it determines a controlled outcome:

  • Retain
  • Delete
  • Preserve
  • Restrict
  • Anonymize
  • Defer
  • Escalate for review
§3Platform components

Ten components, one governance architecture.

A layered, rules-driven information-governance platform that brings Records Management and Data Privacy into a common software architecture.

  1. 01Unified Information Governance ModelRepresents information assets, record classes, retention requirements, privacy classifications, ownership, stewardship, processing purposes, jurisdictions, legal holds, and lifecycle states.
  2. 02Records Management EngineRecord classification, retention schedules, retention triggers, legal holds, disposition eligibility, archival, and defensible disposition.
  3. 03Privacy Rules EngineEvaluates applicable U.S. privacy requirements, consumer rights, data categories, jurisdictional conditions, processing purposes, and exceptions.
  4. 04Versioned Policy & Regulatory Rules LayerMaintains effective dates, rule versions, superseded rules, and historical policy states so earlier decisions can be reconstructed.
  5. 05Conflict-Resolution EngineEvaluates competing requirements, such as a privacy deletion request versus a records-retention requirement or legal hold, before determining the permitted action.
  6. 06Identity & Data-Subject ResolutionIdentifies the same individual across multiple systems and identifiers.
  7. 07Workflow & Orchestration LayerCoordinates privacy requests, records lifecycle actions, exception handling, approvals, and downstream execution.
  8. 08Integration & Connector LayerSeparates the governance decision from system-specific execution, so one decision can be carried out across databases, SaaS applications, document repositories, archives, and APIs.
  9. 09Audit & Decision-Provenance LayerRecords the basis for each decision: rule and version, classification, retention obligation, privacy requirement, exception, resulting action, and execution evidence.
  10. 10Regression & Validation FrameworkTests new rules, jurisdictions, record types, and integrations to determine whether changes affect previously supported scenarios.
§4Architecture

From source system to evidence trail.

  1. Enterprise data sources & repositories
  2. Discovery & metadata ingestion
  3. Unified records & privacy governance model
  4. Classification & applicability evaluation
  5. Versioned rules & policy engine
  6. Conflict-resolution engine
  7. Governed action
  8. Workflow & orchestration
  9. System-specific execution
  10. Audit & evidence trail
§5What sets it apart

One decision model, with its reasoning preserved.

i.

Unified

Records Management and Data Privacy operate through one common governance-decision architecture, rather than as separate applications that must be reconciled manually.

ii.

Versioned

The architecture preserves which rule version applied when a decision was made, so it can be reconstructed later, even after privacy laws or retention policies change.

iii.

Explainable

Each material decision links source information, classification, jurisdiction, rule version, retention requirement, privacy right, exception, decision, execution, and result.

§6Research basis

Our research activities, described against the four-part test.

The Recova program is organized as technical research. Below, its activities are described under the four parts of the IRS four-part test for research activities.2 This is a description of the work, not a determination of its tax treatment.

1

Permitted purpose

A new information-governance architecture

The objective is to develop and experimentally validate an enterprise software architecture that integrates records lifecycle management and privacy governance in one framework. The goal is to represent varied governance requirements as structured, executable, version-controlled rules tied to actual enterprise information assets.

  • Function: evaluate records, privacy, legal-hold, regulatory and lifecycle conditions together before choosing an action, instead of keeping Records Management and Privacy in separate applications.
  • Reliability: produce consistent, deterministic, testable decisions, and reproduce earlier decisions after rules change.
  • Quality: keep a complete evidence chain for each material decision, and add new laws, record types and repositories without redesigning the core or causing regressions.
  • Performance: study behavior as asset inventories, rule combinations and concurrent requests grow.

The original target was a Records Management platform with integrated privacy capabilities. It has since become a version-controlled information-governance decision platform.

2

Technological in nature

Grounded in software architecture and computer science

The research questions are about the capability, method and design of software. They are not business planning, and they are not legal interpretation alone. The regulations are an input. The work is in how requirements are modeled, versioned, evaluated, reconciled, executed, tested and audited in software. The technical areas involved include:

  • information metamodeling: attributes, objects, relationships, derived classifications or hybrids
  • rule representation: hard-coded logic, decision tables, rules engines, domain-specific languages, graph-based policies, event-driven rules and temporal logic
  • temporal versioning, with time treated as a first-class part of the architecture
  • identity resolution across systems, using multiple identifiers and confidence-based matching
  • distributed execution through a connector abstraction layer, handling partial failures, retries and recovery
  • performance factors such as indexing, caching, event processing and relationship traversal
3

Elimination of uncertainty

Capability, method and design were not known at the outset

The team understood the desired capabilities at the start. It had not settled the right method or architecture for building them. The open questions were:

  • Design: how record classes, retention schedules, privacy classifications, consumer rights, processing purposes, legal holds, exceptions and lifecycle states can coexist in one model without too much complexity or conflicting relationships.
  • Method: how to represent, prioritize and evaluate retention-versus-deletion conflicts in software; whether differing U.S. state privacy requirements can share a reusable rules framework; and which rule-representation approach stays configurable yet predictable.
  • Capability: whether the correct historical rule version can be applied and replayed; whether one individual can be identified reliably across systems; whether a decision can run across repositories that work differently; and how to handle missing or conflicting metadata safely.
  • Extensibility and scale: whether new rules or jurisdictions change outcomes that worked before, and how the architecture behaves as assets, rules and workflows grow.

These questions could not be answered at the design stage. The right behavior depends on how many conditional rules interact, privacy requirements vary by jurisdiction and change over time, and enterprise systems and metadata vary widely. These effects show up only once a design is built and tested.

4

Process of experimentation

Alternatives evaluated through prototyping, testing and iteration

Alternatives considered: separate Records and Privacy modules; a single consolidated schema; a shared governance core with specialized components; and a rules-based or relationship-driven architecture. They were weighed against these criteria: multi-jurisdiction and version support, reconciling retention with deletion, extensibility, decision provenance, integration, testability, regression risk and auditability.

hypothesis → software change → controlled records/privacy scenario → execution → observation → comparison with expected behavior → refinement → regression test

Testing: unit, rules, scenario and combinatorial testing (for example, jurisdiction × rule version × record class × privacy right × retention status × legal hold × exception × repository), plus boundary, negative, integration, fault-and-recovery, regression and historical-replay testing. Scale and performance testing is planned as the work expands. Results are classified to separate software defects from design limitations, which are architectural findings.

What the experiments changed: the design moved toward a shared governance model, a centralized conflict-resolution layer, configurable version-controlled rules, historical decision tracking, stronger metadata validation and escalation, decisioning separated from system-specific execution, and full decision provenance.

[Placeholder: summary of experimental results / findings, if publishable]
§7Status

A research preview of an evolving design.

Research preview. Recova is shared here as a preview of ongoing research. It is not currently offered to clients, and this page describes an evolving design rather than a finished product. Work planned for later phases, including broader validation, scalability, more jurisdictions and integration expansion, is planned research, not completed work.

[Placeholder: Recova logo / product mark]

Notes

  1. Recova is under active R&D [Placeholder: confirm public R&D timeline, e.g. Oct 2024 – Dec 2027]; descriptions reflect the current design, not a finalized product. ↩
  2. The framework used in §6 is the four-part test for qualified research under Internal Revenue Code §41 (permitted purpose, technological in nature, elimination of uncertainty, process of experimentation). It is used here only to organize the description. ↩

Research preview

Follow our research on records and privacy governance.

Recova is an active R&D program. Questions about the research are welcome.

Ask about Recova →Read about the SGF