How we work with you.
LStore is open and freely available — the platform is developed in the open and can be downloaded and run by anyone. What Unique Checksum provides is everything around the software: the architecture, the integration, the hardware, the support, and the operational expertise that turn an open platform into a production system an institution can stand up with confidence and run as its own. This page describes how a Unique Checksum engagement is structured, where operational ownership sits, and the two relationship patterns an institution can choose between.
You own and operate; we make it deployable.
The defining fact of a Unique Checksum engagement is that the institution owns and operates its own infrastructure. Unique Checksum designs the system, integrates the components, delivers a complete production-ready solution, and supports it — but the institution runs it. This is true across every engagement and every relationship pattern. It reflects how LStore actually works: an open platform that an institution could run on its own, made genuinely deployable and supportable by the work Unique Checksum brings around it.
This framing matters because it sets the relationship correctly from the outset. Unique Checksum is not a managed-hosting provider that runs storage on an institution’s behalf, and it is not a software licensor gating access to a proprietary product. It is the engagement and accountability owner for delivering a complete LStore solution — the firm an institution engages to take an open, powerful, but bare platform and turn it into production infrastructure sized, built, integrated, and supported for that institution’s actual needs.
The work divides cleanly. Unique Checksum brings the platform expertise: the architecture, the placement and reliability and lifecycle design described across the rest of these pages, the integration of the storage with orchestration and tape tiers, the hardware specification, and the support structure. The institution brings its infrastructure, its environment, its domain knowledge, and the team that will own the running system. The engagement is the disciplined process of combining those into a deployment, and the relationship that follows is the institution’s to shape — described in the two patterns later on this page.
Every engagement is scoped explicitly, with defined objectives, deliverables, and acceptance criteria agreed up front, so that both parties know what success looks like before the work begins. The Services page describes the broader consulting practice an institution can engage independent of a platform deployment; this page is about the platform deployment itself.
Open software, engineered solution.
LStore is open. It is developed in the open, its source is available, and an institution with the expertise and the appetite to do so can download it and run it without engaging anyone. Unique Checksum states this plainly because it is the honest foundation of the commercial offering: the value is not access to the software. The value is everything required to make the software into a dependable production system — and for most institutions, that everything is considerable.
The gap between a powerful open platform and a production deployment is where real infrastructure projects succeed or fail. It is the architecture decisions that match the platform to the workload; the hardware selection and the integration of heterogeneous components into a coherent fleet; the placement policy, the reliability configuration, and the lifecycle orchestration that have to be designed rather than defaulted; the operational practice that sustains the system once it is live; and the support structure that an institution depends on when something needs deep expertise. None of that is in the download. All of it is what Unique Checksum delivers.
This is deliberately the opposite of a lock-in posture. An institution that engages Unique Checksum is not buying a key to a locked door — the door is open. It is buying the engineering, integration, and support that make walking through it a sound decision rather than a research project. Institutions that have the in-house capability to self-integrate are welcome to; the platform is genuinely available to them. Unique Checksum exists for the institutions that would rather engage expertise that has already done it at production scale, and for the ongoing support relationship that a critical storage system warrants regardless of who stood it up.
The openness of the platform is also what keeps the broader ecosystem healthy. The research-computing community that develops and uses LStore continues to do so in the open; Unique Checksum’s commercialization work complements that openness rather than enclosing it. The platform stays available to everyone, and the solution-and-support layer is what is offered commercially.
From requirements to production-ready.
A greenfield LStore deployment — standing up the platform as new infrastructure for an institution — follows a disciplined sequence from requirements analysis through to a production-ready system handed to the institution’s team. The phases below describe the shape of that work. Each engagement is scoped to its own objectives, but the arc is consistent.
-
01
Requirements & architecture
Analysis of the institution’s workload, data profile, growth trajectory, and integrity requirements, producing a storage architecture matched to them — the tiering strategy, the reliability design, the capacity plan, and the cost trajectory of the choices.
-
02
Hardware specification
Specification of the hardware that will run the deployment well, drawing on LStore’s demonstrated tolerance for heterogeneous, multi-generation fleets. Unique Checksum maintains the certified-compatible-hardware list for LStore and specifies against it.
-
03
Integration & build
Assembly of the complete solution — the distributed file system, the orchestration layer, and, where the institution’s retention needs call for it, the tape archive tier — integrated into a single coherent system rather than a set of parts the institution must wire together itself.
-
04
Deployment & validation
Standing the system up in the institution’s environment, configuring placement and lifecycle policy to the workload, and validating that it performs and behaves as designed before it carries production data.
-
05
Operational handoff
Transfer of operational ownership to the institution’s team, with the operations practice documented and the team equipped to run the system. The handoff is described in the next section; what happens after it is the institution’s choice between the two patterns that follow.
The integration phase is where the “complete solution” language earns its meaning. An institution does not receive a file system and a list of other things to go acquire and connect. It receives a system in which the storage platform, the orchestration that directs data placement across tiers, and — where needed — the tape preservation layer are already integrated and validated together. The components of that solution are delivered through Unique Checksum’s partner ecosystem, described in Section 06.
Where ownership becomes yours.
Every engagement has a handoff line: the point at which operational ownership of the running system passes to the institution’s team. Before it, Unique Checksum is building and validating; after it, the institution is operating. The line is the same in both relationship patterns — in both, the institution self-operates. What differs is whether Unique Checksum’s relationship with the institution continues past the line, and in what form.
The handoff transfers operation, not dependence. The institution runs its own system on its own infrastructure — with as much or as little ongoing relationship as it chooses.
Defining the handoff line precisely matters because it is the thing institutions most need clarity on before they engage. A managed-service relationship never hands off — the provider operates indefinitely, and the institution never owns the capability. A pure product sale hands off immediately and completely — the institution is on its own from day one. A Unique Checksum engagement is neither: it hands off operational ownership deliberately, once the system is production-ready and the institution’s team is equipped to run it, so that the institution genuinely owns its infrastructure — and then offers a continuing relationship as an option rather than an obligation.
This is the same posture as the platform’s openness, expressed in the relationship rather than the software. Just as the institution is never locked out of the platform, it is never locked into operational dependence on Unique Checksum. It owns the running system. Whether it also wants an ongoing partnership is a separate decision, and the two patterns below are the two answers to it.
Turnkey delivery, or ongoing partnership.
Both patterns begin with the same greenfield delivery and the same handoff of operational ownership. They differ in what the relationship looks like afterward. An institution chooses the one that fits how it wants to operate — and the choice is not permanent; a turnkey delivery can become an ongoing partnership later if the institution’s needs change.
Turnkey delivery
Unique Checksum designs, builds, integrates, and stands up the complete system to production-ready, then hands operational ownership to the institution’s team. The institution operates independently from there, with the system documented and the team equipped to run it.
Support and advisory remain available if the institution wants them, but the engagement is structured as a delivered solution rather than a continuing relationship.
Ongoing partnership
The same delivery and handoff, followed by a continuing relationship: annual support for the hardware and software components, continued architecture advisory as the workload evolves, and the ability to grow capacity and capability into the existing relationship as requirements expand year over year.
The institution still owns and operates its system. Unique Checksum stays engaged as the platform expertise behind it — the escalation path, the advisor, and the source of growth as the deployment scales.
The two patterns are points on a spectrum rather than a rigid binary. Some institutions begin with a turnkey delivery and add a support relationship a year later as their deployment becomes more central to their operations. Others know from the outset that they want a long-term partnership. The engagement is scoped to whichever fits, and the relationship can deepen as the institution’s reliance on the platform grows. What does not change is the underlying posture: the institution owns and operates its system, and the relationship is shaped to its preference rather than to a fixed service model.
A lead integrator, coordinating an ecosystem.
A complete LStore solution draws on more than one organization. Unique Checksum acts as a lead integrator for the engagements it leads — coordinating the partners whose components make up the delivered solution so that the institution engages a coherent whole rather than assembling parts from multiple vendors itself. The ecosystem is forming, and partners will be named as those relationships are announced.
The integrator role is what makes the “complete solution” promise real. Behind a delivered LStore deployment are the platform itself, the orchestration layer that manages tiered data placement, the hardware that the system runs on, and — where retention requirements call for it — the tape preservation tier. These come from different organizations with different specialties. Unique Checksum’s role for the engagements it leads is to coordinate them into a single integrated delivery, so that the institution has a coherent solution and a clear line of accountability rather than a procurement project across multiple independent vendors.
One partner is already named: Spectra Logic, whose tape libraries provide the long-term preservation tier in deployments that need one, with Unique Checksum as a Spectra EDGE Partner. Others — in orchestration, in hardware, in the platform’s ongoing development and support — are part of the forming ecosystem and will be named as those relationships are announced. The engagement model does not depend on enumerating them; it depends on Unique Checksum coordinating them, which is the role it holds for the engagements it leads.
Support follows the same integrated model. An institution with an ongoing partnership has a defined support structure with front-line response and escalation to deep platform expertise — a tiered model appropriate to critical infrastructure, coordinated through Unique Checksum so that the institution has a clear path to resolution regardless of which part of the solution a question touches.
A deployment that grows with you.
Research-computing storage is rarely static. Data volumes grow, workloads shift, new tiers of media become economical, and the requirements that shaped the original deployment evolve. The ongoing-partnership pattern is built for this: a relationship in which the institution’s deployment grows in step with its needs, with Unique Checksum as the expertise that plans and delivers each expansion.
The growth is concrete. As an institution’s data outgrows its initial capacity, additional depots and drives are specified, acquired, and integrated into the existing fleet — an operation LStore is specifically designed to accommodate, since its placement model absorbs new resources without disruption. As workloads change, the lifecycle and placement policy are revisited and retuned. As new media classes become economical, new tiers can be introduced. Each expansion is scoped, delivered, and integrated into the running system the same disciplined way the original deployment was.
This is also where the relationship compounds in value. An institution that has run its LStore deployment for a year through an ongoing partnership has a Unique Checksum that knows its environment, its workload, and its trajectory — which makes each subsequent expansion faster to plan and lower-risk to execute than it would be for a vendor encountering the environment fresh. The partnership is an investment that pays back in the quality and speed of every expansion that follows.
The annual support relationship underpins all of it: the hardware and software components covered, the escalation path maintained, the advisory available as questions arise. For an institution whose storage is central to its mission, that continuity is the point — the system is theirs, they operate it, and the expertise that built it remains available as it grows.
An open platform, delivered with discipline.
The engagement model reflects the same discipline that runs through every other page on this site. The platform is open and the institution owns its system; what Unique Checksum brings is the engineering, integration, and operational expertise that turn an open platform into dependable production infrastructure — delivered through a defined process, handed off cleanly, and supported as long as the institution wants it.
For an institution evaluating LStore, the practical path is a conversation about its workload, its scale, and its trajectory — the inputs that determine the architecture, the hardware, and which engagement pattern fits. From there the engagement is scoped explicitly, with the objectives and deliverables defined before the work begins. The technical pages neighboring this one describe what is being deployed; this page describes how the deployment is delivered and supported; the next step is to talk about the specifics of a given institution’s needs.
The same operational philosophy described under Reliability & Integrity, Operations & Lifecycle, and the broader integrity heritage of the firm applies to the engagement itself: do the disciplined thing deliberately, document it, and sustain it. An institution’s storage is too important to deploy any other way.