Skip to main content
Skip to application content

Trace …

Data Approved sample data

  1. Image analysed
  2. Review action recorded
  3. Batch loaded
  4. Evidence opened
  5. Assistant answered

0 of 5 workflow steps

Guided demo

Technology

Architecture and integration view of the demonstration path: typed service contracts, session traceability and the platform building blocks behind them.

Data mode: Approved sample data

Data flow

The demonstration path from a selected sample to the areas that consume its output.

  1. Sample intake
  2. Checksum verification
  3. Technical checks
  4. Analysis adapter
  5. Research output + review state
  6. Session trace
  7. Batch / evidence / assistant

Service interfaces

The typed adapter mounted per capability under the current data mode.

Image analysis

Approved-sample adapter

  • analyse(request: AnalysisRequest)

Returns reviewed sample scenarios labelled approved-sample-scenario.

Functional Prototype

Batch

Approved-sample adapter

  • loadApprovedSample()
  • previewFile(file: File)

Returns reviewed sample scenarios labelled approved-sample-scenario.

Functional Prototype

Assistant

Approved-sample adapter

  • ask(input: { question, context? })

Returns reviewed sample scenarios labelled approved-sample-scenario.

Functional Prototype

Provenance fields

Every analysis result carries this Provenance record so its origin is always explicit.

dataMode
Which data mode produced the output: approved-sample or live-service.
outputSource
Whether the output is an approved-sample scenario or a live service response.
scenarioVersion
Version identifier of the approved sample scenario set.
wrapperVersion
Version of the frontend wrapper that shaped the output.
modelVersion
Reads "Not supplied" because no approved historical model version was provided.
preprocessingVersion
Reads "Not supplied" because no approved historical preprocessing version was provided.
integrityVerified
Whether the sample checksum matched the expected value.
sha256
Checksum of the sample image used for the analysis.

Platform building blocks

Architectural areas of the demonstration.

Platform architecture

A browser-based application layer, a typed service interface and modular AI services that can be developed independently.

  • Browser application for image, batch, evidence and assistant workflows
  • Typed service interface between the interface and platform services
  • Modular services so image, analytics and AI work can progress separately

Image intake and technical checks

Images enter through a single intake path that records file metadata, validates supported formats and attaches a trace identifier.

  • Supported-format and file-size validation in the browser
  • File metadata, dimensions and timestamp captured at intake
  • Trace identifier attached to every image interaction

Batch analytics

Structured records are imported, validated against a schema and summarised entirely from the loaded data.

  • CSV and JSON import with schema validation
  • Totals, status distribution and failure reasons derived from loaded records
  • Filtering, sorting and export back to CSV or JSON

Evidence Hub and retrieval

Approved product and technical sources are stored as structured records that can be searched and cited.

  • Source title, type, review date and citation identifier on every record
  • Search and source-type filtering across the record set
  • Stable record links usable as citation targets

AI Assistant and source citations

The assistant is designed around retrieval over approved sources, so every answer can be traced to the records behind it.

  • Question interface with suggested entry points
  • Answers presented with the citations that support them
  • An explicit response when the approved sources do not cover a question

Traceability and versioning

Interactions carry identifiers and timestamps so work can be reconstructed and reviewed later.

  • Trace identifier and timestamp on image and batch interactions
  • Versioned evidence records with review dates
  • Exports that carry their source record identifiers

Next priorities

Planned research and integration work, not delivered capability.

  1. 1

    Subject-disjoint evaluation

    Evaluate on splits that prevent subject leakage between training and test data.

  2. 2

    Probability calibration

    Study whether model output can be made interpretable as a calibrated probability.

  3. 3

    Selective prediction and abstention

    Investigate when a model should decline to produce an output.

  4. 4

    Input-quality and out-of-distribution research

    Detect fields that fall outside the modelled input distribution.

  5. 5

    EfficientNet benchmarking

    Benchmark a convolutional baseline against the platform reference workflow.

  6. 6

    DinoBloom research

    Assess whether domain feature representations suit blood-cell image tasks.

  7. 7

    Explainability experiments

    Explore region attribution as a review aid, with a written interpretation boundary.

Not for diagnosis or clinical decision-making.

Approved sample data only · no patient data · nothing transmitted