Observables Are Observables: Why Sprite's Model Doesn't Have to Stop at Digital
The latest addition to Sprite is a plugin called cellesprite that ingests Cellebrite clbe exports directly into the platform. It's a useful piece of work. The interesting bit isn't the plugin itself, though. It's that adding a new evidence source to Sprite turns out to be mostly a matter of mapping what's in the source format to Sprite's observable model - and once it's in, the rest of the platform doesn't care where it came from.
That made me start thinking about a question I'd been avoiding for a while: does the model have to stop at digital evidence?
What an Observable Actually Is
Strip Sprite down to its core abstraction and you get observables. An observable is a typed record describing something we found: a file, a message, a phone number, an account, an image. Each one has properties (its facets, in CASE/UCO terms), provenance recording where it came from, relationships to other observables, and a place in a chain of custody.
Nothing in that list is intrinsically digital. "Typed record describing something we found, with provenance and relationships" is a fairly clean description of evidence in general. It's just that Sprite, like every digital forensic tool, has been working with types where the somethings are bits.
A DNA Profile Is Just Another Observable
Imagine, for the sake of argument, that Sprite had to deal with a DNA profile. What would that actually require?
You'd need a type - call it dna_profile - with facets for the loci examined, the alleles called at each locus, the kit used, the analyst, the lab, and the source sample. Provenance is the same idea as for any other observable: where did this come from, who acquired it, what's the chain of custody. Relationships are familiar too: this profile was extracted from that sample; this profile is a partial match to that one with a likelihood ratio of x; this profile is excluded from that comparison.
A DNA matching plugin then becomes the same kind of thing as a hash matching plugin. Take an observable, query a reference set (a CODIS-style database, or an internal one), emit relationships and findings. A statistical plugin computes likelihood ratios. An export plugin produces a report in whatever format the receiving lab or court expects. Every primitive Sprite already has - chain of custody, audit, governance, AI plugins, search, cross-case correlation - works on these observables for the same reason it works on file hashes and message threads.
You'd need new types. You wouldn't need a new platform.
Footprints, Fibres, and Other Things That Don't Live in Phones
The same logic applies further out. A footwear impression is an image with a tread pattern, dimensions, and wear characteristics. A fibre is a sample with a colour, a microscopy image, and a chemical signature. A toolmark is an image with measurable features and a reference comparison. A questioned document is, well, a document - Sprite already handles those, just for different reasons.
Some of these are image-based, and Sprite already supports image observables, similarity matching, and AI-driven pattern recognition. Some are signature-based, spectra, chromatograms, and would need a type that carries the underlying data alongside its derived properties. Either way the work is in defining the types properly, not in re-architecting the platform.
The interesting bit is what happens once those types are in. A real case file usually isn't "the digital case" or "the DNA case." It's a subject, with multiple kinds of evidence pointing at, or away from, them. The same person who owns the phone is the same person whose DNA might be on the recovered item is the same person whose shoes might match the impression at the scene. Sprite's relationship graph is built for exactly that kind of cross-evidence linking. It just hasn't had cross-discipline data to link yet.
Different Users, Different Frontends
Cross-discipline data is only useful if the right people can actually see it, and the right people aren't all looking at it the same way. An examiner working through a phone wants depth: every observable, every artefact, every relationship, with the ability to pivot and re-run analysis. An intel analyst looking at the same case wants links, networks, and patterns across subjects. A senior investigating officer wants a case-level view: where are we, what's been found, what decisions are pending, what's heading to the strategy meeting on Thursday.
These are three different products dressed up as one. Sprite handles them as three different frontends.
We've already built more than one. Alongside the main examiner UI there's a management frontend for customer and licence administration, and an intel-frontend aimed at analysts who need link analysis and aggregation rather than artefact-level depth. They all talk to the same platform API. They all pull from the same observable store. The differences are in the workflows and the visualisations, not the data underneath.
An SIO frontend would follow exactly the same pattern. So would a defence-reviewer frontend, a court-facing exhibit viewer, or whatever a particular customer's investigation actually needs. None of those are platform projects. They're UI projects, because the platform is the data layer and the API, and the frontends are just clients.
Combine that with the cross-discipline argument and you arrive somewhere genuinely useful: an SIO view that pulls together digital, DNA, and trace observations on a subject in a single timeline, because the underlying data model treats them all the same way and the frontend just has to render them. The examiner who originally produced the digital evidence sees their depth view. The DNA analyst sees their workflow. The SIO sees the joined-up picture. Same data, three windows.
What It Would Actually Take
I'm not pretending we've done this. We haven't. Sprite is digital-forensics-first, and that's where every plugin we ship today lives. There's real work between "the architecture supports it" and "the architecture is accredited for it."
Each discipline has its own validation regimes, accreditation bodies, and court-admissibility standards. Defining the types correctly takes domain expertise we don't have in-house. That's a partnership question, not a software question. Ingesting from instruments (sequencers, comparison microscopes, GC-MS rigs) means writing connectors with vendors who, in their own way, have the same closed-format habits as digital forensic vendors. We'd be back to writing the same kinds of plugins we write today, against a different set of source formats.
We're also not trying to be a LIMS. There are good lab information management systems and they do what they do. The question Sprite answers is a different one: when an investigation pulls evidence from multiple disciplines, where does it all come together, and how does an examiner or an analyst, or an SIO - reason across it? That's an interoperability problem, not a lab management one.
The Architecture Doesn't Care
The architectural decisions Sprite has already made - open data, CASE/UCO alignment, plugins as the integration boundary, relationships as first-class, multiple frontends over a shared API, governance and audit baked in - were made because they're the right decisions for digital forensics. They happen to also be the right decisions for any forensic discipline that needs to express findings, link them, audit them, and present them to whoever needs to see them.
That's not the same as saying it'll happen tomorrow. It is the same as saying we shouldn't pretend the model only works for bits, or only works for examiners. Forensics is a wider field than digital, the cases that matter usually pull from more than one part of it, and the people who need to make sense of those cases are a wider group than the people doing the technical extraction.
The types aren't there yet. The frontends aren't all there yet. Neither is impossible.