Adopting CASE Investigation Ontology by Communities with Defined Business Rules

[vulnmaster]

Background

CASE includes an Investigation ontology that provides durable primitives (e.g., investigation:Investigation, investigation:InvestigativeAction, investigation:Authorization, investigation:ProvenanceRecord, and investigator/examiner/attorney roles). This change proposes adding two lightweight, non-prescriptive process meta-model ontologies—one oriented to law-enforcement investigations and one to corporate investigations—so organizations can extend them in their own namespaces and build workflow/process-oriented applications on top.

What we achieve for whom and why it matters: Organizations gain a shared, interoperable scaffolding to represent investigation workflow structure (templates, steps, gates, assignments, statuses, and execution runs) while still grounding the actual investigative work in CASE Investigation semantics—enabling consistent reporting, auditability, and cross-tool interoperability without forcing a single “correct” process.

Requirements

Requirement 1

Define a reusable process meta-model aligned to CASE Investigation, including concepts for:

• Process templates vs. process runs (execution instances)
• Work items / steps that can be linked to investigation:InvestigativeAction
• Status/state and transitions (at least a minimal state vocabulary or extensible hook)
• Decision gates / approvals (first-class objects)
• Assignments (actor/role-based)
• Milestones and constraints (e.g., due dates/SLAs as optional metadata)
• Explicit linkage points to investigation:Investigation, investigation:Authorization, and investigation:ProvenanceRecord

Requirement 2

Publish two domain-scoped ontologies that import and reuse the shared process meta-model:

• CASE-Process-LE: law-enforcement oriented scaffold (authorization gating, evidence handling checkpoints, prosecution/court-facing handoffs as abstract milestones)
• CASE-Process-Corporate: corporate oriented scaffold (internal mandate/authority, legal hold & preservation, HR/Legal decision gates, regulatory/referral decisions, remediation linkage as abstract milestones)

Both must remain non-prescriptive: provide optional example stage/gate categories and recommended modeling patterns, but do not hardcode a mandatory sequence of steps.

Risk / Benefit analysis

Benefits

• Enables workflow applications to be built on top of CASE using a shared vocabulary (task lists, gates, status tracking, assignments, audits).
• Improves interoperability across orgs and tools by separating “how we run work” (process) from “what occurred” (investigation facts/actions).
• Reduces ontology forking: orgs can extend via their own namespace modules (profiles) rather than altering CASE Investigation.
• Supports governance/audit needs: explicit approval points, traceable action dependencies, and linkage to authorizations and provenance.
• Allows multiple workflow styles (linear, parallel, iterative) using dependencies rather than imposing a single pipeline.

Risks

• Risk of overlap/confusion with investigation:InvestigativeAction if “step/work item” is modeled redundantly. Mitigation: specify that investigative work remains expressed as investigation:InvestigativeAction, and process “work items” primarily organize/track execution, optionally referencing actions.
• Risk of prescriptiveness creeping into the LE/corporate scaffolds (too many “official phases”). Mitigation: keep phase/gate lists as illustrative examples and provide “informalType”/extensibility hooks.
• Risk of insufficient adoption if implementers want stronger constraints. Mitigation: provide optional SHACL profiles (separate artifacts) for common organizational constraints without embedding them in OWL axioms.
• Risk of added maintenance surface area (two new ontologies + shared meta-model). Mitigation: keep the shared meta-model minimal and stable; treat domain scaffolds as thin layers with examples and documentation.

Competencies demonstrated

Competency 1

Scenario: An organization runs a digital investigation using a workflow application. The organization has a defined investigation process template with several steps (triage, scoped collection, analysis, reporting). Some steps require approvals/authorizations. During execution, multiple investigative actions occur in parallel, and certain actions are blocked until approvals are granted. The organization wants an interoperable representation of (a) what happened procedurally (statuses, assignments, approvals) and (b) what happened investigatively (actions, provenance, authorization artifacts).

Competency Question 1.1

For a given investigation:Investigation, what are the currently open workflow work items, their statuses, and assignees?

Result 1.1

A client can query the linked process:ProcessRun for process:hasWorkItem items with status in {Open, InProgress, Blocked}, returning each item’s status, due date (if present), and process:assignedTo / process:assignedRole.

Competency Question 1.2

Which investigative actions are blocked pending an approval/authorization decision, and what authorization/gate is required?

Result 1.2

A client can query process:WorkItem objects (or linked investigation:InvestigativeAction objects) that have process:blockedByGate and/or process:requiresAuthorization, returning the gate decision state and the referenced investigation:Authorization (or authorization requirement type).

Solution suggestion

• Create a new shared ontology module: CASE-Process-Core (or equivalent name) that imports CASE Investigation and defines:
  • process:ProcessTemplate, process:ProcessRun, process:WorkItem, process:Gate, process:Milestone, process:Assignment, process:Status (or status hook), plus linking properties to Investigation/Action/Authorization/Provenance. We may instead model this by extending another existing process ontology. These are only examples to get the conversation started.
• Create two thin domain modules that import CASE-Process-Core:
  • CASE-Process-LE: optional example phase/gate categories and documentation focused on LE needs.
  • CASE-Process-Corporate: optional example phase/gate categories and documentation focused on corporate needs.
  • Extend to Align to new CASE Investigator Roles
• Provide minimal example instance data for each domain module demonstrating:
  • A template and a run
  • 4–6 work items with statuses/assignments as an example that can be updated/extended by adopters
  • At least one gate requiring approval/authorization
  • Linkage to investigation:InvestigativeAction and investigation:ProvenanceRecord
• Add implementation tests:
  • OWL consistency checks
  • SHACL (optional) profiles as separate artifacts for common constraints (e.g., “collection requires authorization”) with positive and negative example graphs. The adopter can further improve this with their local business rules.
• Documentation updates:
  • Modeling guidance emphasizing non-prescriptive nature and recommending dependency modeling via action provenance/dependency relationships rather than forced ordering.