Use an ontology-backed workflow rather than Microsoft 365 Power Platform

Why

Historical reports needed to remain intuitive to find and use. Modeling reports and their lifecycle in the ontology created a stronger connection between current workflow actions and persistent historical records.

Alternatives considered

  • Build the workflow in Microsoft 365 / Power Platform
View the case study →

Model each reporting level as a structured report type with explicit lifecycle actions

Why

Reviewers needed to select relevant subordinate inputs and build the next report without dropping back into manual consolidation. Explicit report types and actions made that transition part of the application rather than an informal handoff.

View the case study →

Use ISA as the canonical downstream representation

Why

A canonical model gives downstream components a stable target even when upstream sources use different schemas and terminology. The proof of concept therefore translates normalized transport records into ISA constructs rather than propagating source-specific structures through the system.

View the case study →

Package validation and diagnostics with the integration

Why

A proof of concept is more useful when another technical team can reproduce the path and see where failures occur. Initialization, proof scripts, diagnostics, and repeatable packaging were treated as part of the implementation rather than after-the-fact documentation.

View the case study →

Keep the baseline and knowledge branch separable through late fusion.

Why

Late fusion made it possible to compare baseline-only and augmented predictions directly, isolate the effect of external knowledge, and run controlled ablations without retraining the full vision-language model.

Alternatives considered

  • End-to-end retraining with knowledge injected earlier in the model
  • Prompt-only or retrieval-only approaches without a controlled fusion layer
View the case study →

Bound the ConceptNet slice instead of retrieving an unrestricted neighbourhood.

Why

ConceptNet includes large amounts of generic or weakly relevant information. Explicit limits on entities, hops, relations, neighbours, edge weights, and top-K facts made the retrieval process testable and reduced uncontrolled noise.

View the case study →

Treat a negative result as a diagnostic outcome rather than hide it.

Why

The research question was whether the technique worked under matched conditions. Preserving configuration-linked results and failure analysis was more defensible than tuning toward an unsupported positive claim.

View the case study →

Treat the problem as a lifecycle rather than a registrar-owned workflow

Why

Interviews showed that registrar decisions are important but do not explain or own every blocker. All arrivals initially pass through a holding/in-processing function, while later hold populations can exist elsewhere. The system therefore needs to represent transitions and ownership across organizations.

View the case study →

Design around actionable work populations instead of disconnected dashboards

Why

An attention indicator is useful only if it leads users to the population they can actually work. The prototype therefore connects exceptions to the relevant roster/work view rather than creating separate summary screens with no resolution path.

View the case study →