Industry solution

Science & Research

Reproducible results, governed data and grants that add up

Connected tools for universities, institutes and R&D groups: lab records, shared data, awards, compute and instruments working as one.

Products
8
Challenges
5
Concepts
15
Talk to us about Science & ResearchAsk a question
Researcher at a lab bench beside an instrument, with a laptop showing a data lineage graph
LabsOfScience(opens LabsOfScience in a new tab)CosmicIntersection(opens CosmicIntersection in a new tab)SemanticFed(opens SemanticFed in a new tab)PlanMagnet(opens PlanMagnet in a new tab)CrewFoundry(opens CrewFoundry in a new tab)VibeControls(opens VibeControls in a new tab)AdapterCloud(opens AdapterCloud in a new tab)AssetHandler(opens AssetHandler in a new tab)

The problem

Why running research is harder than doing the science

Research groups juggle notebooks, shared drives, payroll spreadsheets, cluster accounts and facility calendars that never connect, so results are hard to rebuild, data travels by email and grants are reported from memory.

Most research groups run on a patchwork: an electronic notebook here, un-versioned spreadsheets on a shared drive, a protocol PDF passed from student to student, analysis scripts that only run on one laptop, and a sample inventory in someone's head. The people who hold that knowledge rotate by design. Students graduate, postdocs move on, and every term the lab loses a little of its own memory.

Around the bench sits an administrative layer that is just as fragmented. Awards live with the sponsored-programs office, effort in payroll, instruments in a core facility's calendar, compute across a campus cluster and several cloud accounts, and shared data under agreements filed as PDFs. Funders and journals expect open data, reproducible analysis and accurate reporting, yet almost nothing connects a figure on the page to the run, the data version, the person and the grant that produced it.

The pressure lands on a handful of people: the PI answering reviewers, the research administrator assembling a progress report, the facility manager juggling bookings and service visits, the research computing lead chasing untagged spend. Each is solving a cross-cutting problem with a single-purpose tool, and the hand-offs between them happen by email.

Who this is for

  • Principal investigator / lab head

    Figures that can be rebuilt on request, progress reports compiled from real work, and a lab that keeps its memory as people rotate.

  • Research administrator (post-award)

    Effort that matches the work, aims and deliverables tracked against the award, and reports compiled without chasing every PI.

  • Core facility manager

    Instruments kept in calibration, trained operators at the controls, downtime announced early, and hours recharged to the right grant account.

  • Research computing lead

    Cluster and cloud spend attributed to labs and awards, idle GPUs caught early, and long jobs that survive a dropped connection.

  • Research data steward

    Data use agreements honored, every access grant with a reason and an end date, citable releases, and data management and sharing plans kept honest.

  • Director of research operations

    One connected view of labs, data, compute and facilities, fewer compliance surprises, and no new single-purpose tool per department.

A day in the life

The story behind the solution

A week in the Okafor Lab

Nadia runs a twelve-person atmospheric chemistry group studying how cooking, cleaning and ventilation shape the air inside occupied homes. Her lab shares a mass spectrometer with the chemistry core, trains models on the campus cluster and a departmental cloud account, and pools sensor data with two partner universities under a data use agreement. This is one week in late September, when a paper revision, a progress report and a broken instrument all land at once.

  1. Monday, 8:40 a.m.

    Reviewer 2 wants Figure 4 re-run

    Nadia opens the revision decision over coffee. Reviewer 2 asks for the source-apportionment figure without the 2025 calibration batch, and the response is due in five weeks. Tomás, the postdoc who built the analysis, left for industry in June. The shared drive holds sources_final_v7.csv and a notebook that fails on its first import. Her student Lindiwe spends the morning trying to work out which calibration protocol the bench team used for those samples.

    How this is solved: Figures nobody can rebuild

  2. Tuesday, 10:15 a.m.

    A spreadsheet with ZIP codes in an email draft

    Dr. Kwame Asante, a co-investigator at a partner university, asks for pooled overnight nitrogen dioxide levels by cooking type for a resubmission. Trying to help, a second-year student exports the household table, ZIP codes and all, and attaches it to a draft. Farah Siddiqui, the consortium's data steward, catches it only because she was copied. Nobody can say which of last year's access arrangements are still live.

    How this is solved: Sharing consortium data without exposing participants

  3. Wednesday, 2:00 p.m.

    Three weeks to the progress report

    Grace Holloway, the department's research administrator, writes that the annual progress report is due on October 15. She needs accomplishments by aim, effort for everyone paid from the award and a list of products. Her spreadsheet still shows Arjun, a postdoc, at 75 percent on this award, though half his time moved to another grant in the spring. Aim 2 has slipped since Tomás left in June, his modeling postdoc position is still open, and nothing written down says so.

    How this is solved: Post-award reporting rebuilt from spreadsheets

  4. Thursday, 7:30 a.m.

    A GPU nobody switched off

    Marcus Bell, who leads research computing for the college, flags a jump in the departmental cloud bill: a GPU instance has sat idle since last Friday evening, carrying nothing but a default name. Separately, Lindiwe lost most of a 40-hour interactive model run on the campus cluster when the SSH session holding it dropped as her laptop went to sleep. Nadia cannot tell which award the cloud charges will land on.

    How this is solved: Compute spend nobody can attribute

  5. Friday, 11:00 a.m.

    The mass spectrometer fails its morning check

    Halfway through the lab's booked day, the chemistry core's high-resolution mass spectrometer fails its performance check. Calibration was due last week, but the reminder lived in a personal calendar while the facility manager was away at vendor training. Three more groups have bookings before the service visit, one of them a first-year student whose hands-on sign-off is not finished. Sofia Castillo, who runs the facility, starts calling people one by one.

    How this is solved: Shared instruments that fail mid-booking

None of these moments is unusual; each is an ordinary week in a research group. What makes them expensive is that the answer to each lives in a different system. The solution below is designed so the result, the run, the data version, the instrument, the person, the compute and the grant sit in connected products on one workspace, and each hand-off happens once.

Challenges and how they are solved

5 problems, several products, one connected answer

Each challenge shows the problem as it happens, how the products are designed to hand work to each other, and the concepts that illustrate it. Share any challenge on its own.

Challenge 1 of 5

Figures nobody can rebuild

LabsOfScience(opens LabsOfScience in a new tab)CosmicIntersection(opens CosmicIntersection in a new tab)

The problem

Analysis routinely outlives the person who wrote it. Figures come from renamed files on shared drives and notebooks tied to one laptop, and nothing records which protocol version, calibration batch or data edit fed them. When students graduate and postdocs move on, the environment, the package versions and the reasoning leave with them. A reviewer's request to re-run one panel with a subset excluded becomes weeks of reconstruction from email threads, and the lab often cannot say whether the rebuilt figure matches the published one.

What it costs

Revisions stall, the lab repeats analysis it already paid for, and a result it cannot rebuild is a result it cannot defend to reviewers, funders or the next student who builds on it.

How the products work together

The chain runs in four hand-offs. First, LabsOfScience records the bench: auto-numbered runs under frozen protocol versions, and datasets that grow by checksummed, immutable versions, each frozen version designed to be registered in CosmicIntersection's catalog. Second, a CosmicIntersection notebook with a pinned runtime binds to that registered version and renders the figure. Third, the new LabsOfScience manuscript figure report is designed to record that notebook run as the figure's source and flag drift or a missing source before the response is drafted, so a result is designed to link to its run, dataset version and protocol. Fourth, once a person approves, CosmicIntersection publishes the notebook and dataset versions as a licensed release with a DOI-style persistent identifier, designed to flow back onto the figure record.

The outcome it is designed for

Designed so a reviewer's request becomes a re-run rather than an archaeology project, and every published figure carries a citable, reproducible trail back to the bench.

The concepts behind it

LabsOfScience

Manuscript Figure Reproducibility Report

Maps every figure and table in the revision to its source run, dataset version and protocol, records notebook NB-22 run 14 as the source of Figure 4, and flags items that differ on re-run or have no source.

Works with CosmicIntersection

Concept pagefor Manuscript Figure Reproducibility Report on the LabsOfScience website (opens in a new tab)

Challenge 2 of 5

Sharing consortium data without exposing participants

CosmicIntersection(opens CosmicIntersection in a new tab)SemanticFed(opens SemanticFed in a new tab)

The problem

Multi-site studies run on data use agreements that keep identifying fields, such as home addresses, dates of birth and survey identifiers, at the collecting institution. Pooled questions still arrive constantly from co-investigators, and the fastest route to an answer is usually a hand-built extract sent by email. Access arrangements pile up over years of resubmissions and student turnover, so nobody can say from one place who holds access to which dataset, why, or when it should end, and stewards tend to learn about a risky export only after it has left.

What it costs

One stray export can breach a data use agreement, trigger a report to the IRB and strain the partnership, while legitimate pooled analysis waits on hand-built extracts.

How the products work together

CosmicIntersection catalogs each site's datasets at a restricted or embargoed access level and shares them only through scoped, time-limited grants that record a reason and can be revoked, so the partner's request becomes a grant tied to the agreement instead of an attachment. That grant is what SemanticFed is designed to run under. Address, name and survey-identifier columns are surfaced as column policy proposals that only the data steward can approve, a minimum cell size is set as policy, and the query is designed to be pushed down to each site's own database so only aggregates come back. The new federated cohort query view is designed to show each site's contribution, the masked fields, the suppressed cells and the grant behind the run, and to save the pooled result back to CosmicIntersection as a derived dataset for the release.

The outcome it is designed for

Designed so partners get pooled answers without hand-built extracts, participant-level rows stay at the site that collected them, and every grant has an owner and an end date.

The concepts behind it

SemanticFed

Research Consortium Federated Cohort Query

Is designed to answer the pooled exposure question across all three sites in place, showing per-site counts, masked fields, suppressed cells and the CosmicIntersection grant behind the run.

Works with CosmicIntersection

Concept pagefor Research Consortium Federated Cohort Query on the SemanticFed website (opens in a new tab)

Challenge 3 of 5

Post-award reporting rebuilt from spreadsheets

PlanMagnet(opens PlanMagnet in a new tab)CrewFoundry(opens CrewFoundry in a new tab)LabsOfScience(opens LabsOfScience in a new tab)

The problem

Post-award reporting is usually assembled after the fact. Accomplishments by specific aim live in the PI's memory, effort in payroll spreadsheets that lag every change in appointment, and products such as datasets and papers in individual inboxes. People move between awards mid-year and positions sit open for months, so committed effort and the actual work drift apart without anyone deciding they should. A delay on one aim is often first written down in the progress report itself, weeks before a program officer reads it.

What it costs

Effort commitments that drift from reality create compliance exposure, and a thin or late progress report can hold up the next budget period and weaken the case for renewal.

How the products work together

PlanMagnet holds the award as a plan: each specific aim becomes milestones and deliverables on the award timeline, with the reporting dates the funder expects. Each award is set up as a CrewFoundry project, so allocations are recorded per award, and through the PlanMagnet and CrewFoundry capacity integration each aim is weighed against the people allocated to it. CrewFoundry's utilization heatmap, on its roadmap, is designed to show who is over-allocated across awards and where the open postdoc role leaves Aim 2 short. The new aims and deliverables tracker is designed to read the status of linked LabsOfScience experiments, so progress by aim comes from the bench record. When the report is due, the administrator compiles accomplishments from milestones and effort from CrewFoundry allocations, then reconciles both with the institution's official systems.

The outcome it is designed for

Designed so the progress report is compiled from live milestones, allocations and bench records, and effort mismatches surface months before anyone signs a certification.

The concepts behind it

Challenge 4 of 5

Compute spend nobody can attribute

VibeControls(opens VibeControls in a new tab)AdapterCloud(opens AdapterCloud in a new tab)

The problem

Research computing is spread across a campus cluster, departmental cloud accounts and lab workstations, each with its own accounting, and little of it carries a lab or award tag. GPU instances started for a deadline outlive the job, interactive runs on shared machines die with the connection that launched them, and cloud charges land on whichever account had room. The research computing team sees the bill and the PI sees the award balance, but nobody sees the link between a resource, the person who started it and the grant it belongs to.

What it costs

Unattributed compute lands on whichever award has room, distorting what each grant really cost, and lost runs cost students days they do not have before a deadline.

How the products work together

VibeControls holds long jobs in persistent terminal sessions. On the campus cluster the agent runs on a login node or lab workstation where research computing allows it, and the session holds the scheduler job, so a closed laptop no longer ends a run that anyone can watch or take over from a browser. AdapterCloud inventories the cloud accounts and Kubernetes clusters behind that work, with the cluster's scheduler accounting designed to arrive through a custom adapter, and attributes spend to those resources. The VibeControls agent's target record, with its host or instance id and the vibe's lab and award tags, is designed to be matched to the resource AdapterCloud discovered. The new compute-by-grant view is then designed to group spend by award, flag the idle GPU and name its session and owner, so the lead messages the right student.

The outcome it is designed for

Designed so every compute dollar has a lab, an award and an owner, and long runs survive the ordinary interruptions of a student's week.

The concepts behind it

Challenge 5 of 5

Shared instruments that fail mid-booking

LabsOfScience(opens LabsOfScience in a new tab)AssetHandler(opens AssetHandler in a new tab)CrewFoundry(opens CrewFoundry in a new tab)

The problem

Core facilities run expensive shared instruments for many groups, with calibration intervals, performance checks, service contracts and operator training tracked in separate calendars, binders and spreadsheets. When a check fails, staff work out by hand which bookings fall inside the downtime, who to warn, whether recent runs were out of calibration, and who is trained to run verification once service is done. Whether a new user has finished hands-on training is often known only to the staff scientist who trained them.

What it costs

Downtime ripples across every group that depends on the facility, samples degrade while people wait, and data from an out-of-calibration run can be questioned long after it is published.

How the products work together

AssetHandler holds each instrument as an asset with its calibration interval, preventive maintenance plan, service contract and work orders. LabsOfScience keeps the booking calendar, rejecting overlapping reservations and routing approval-required instruments to the facility. Each LabsOfScience instrument is designed to reference its AssetHandler asset, so opening the work order switches the instrument to under maintenance, the new calibration and downtime board reads the bookings inside that window, and closing the order after verification returns it to service. The facility manager notifies every affected user from the board in one step. CrewFoundry holds the operator learning path and the certificates people earn, designed to carry an expiry; the board lists current operators for post-service verification, and booking is designed to check a new user's certificate first.

The outcome it is designed for

Designed so calibration is scheduled rather than remembered, affected users hear about downtime in one step, and operator training is checked before anyone new reaches the instrument.

The concepts behind it

AssetHandler

Lab Instrument Calibration and Downtime Board

Is designed to track calibration due dates and failed checks, hold the service work order, and list the LabsOfScience bookings and users that fall inside the downtime window.

Works with LabsOfScience, CrewFoundry

Concept pagefor Lab Instrument Calibration and Downtime Board on the AssetHandler website (opens in a new tab)

How it fits together

How it fits together: one award, end to end

Each product does one job in the research lifecycle and hands its output to the next, on one shared identity and audit trail. The hand-offs below are how the products are designed to work together, following one award from its plan through instruments, the bench and partner data to a citable release, and on to the compute it consumed.

  1. To CrewFoundry: Staffing needs and effort per aim, weighed against real team capacity.

  2. To AssetHandler: Operators with current instrument training, listed for verification after service.

  3. To LabsOfScience: A service window that switches the linked instrument to under maintenance for the affected bookings.

  4. To CosmicIntersection: Frozen dataset versions and checksums, registered in the catalog for notebooks and releases.

  5. To SemanticFed: An access grant tied to the data use agreement.

  6. To CosmicIntersection: Pooled, masked aggregates saved as a derived dataset, published with the notebook as a release with a DOI-style persistent identifier.

  7. To AdapterCloud: Session hosts and instance ids, tagged with the lab and the award.

Step 1 of 8: Plan the award

Products in this solution

What each product brings

  • LabsOfScience

    Lab record: runs, protocols, data versions, instruments

    Its signed notebook, frozen protocol versions, checksummed dataset versions and overlap-safe instrument booking are built around reproducibility, the core of the bench side of research.

    Visit LabsOfScienceAll concepts

  • CosmicIntersection

    Data catalog, reproducible notebooks and citable releases

    Built for data-intensive science beyond astronomy: governed access grants, notebooks with pinned environments, end-to-end lineage and citable releases turn shared data into reusable, credited output.

    Visit CosmicIntersectionAll concepts

  • SemanticFed

    Federated queries across partner sites' data

    Queries data where it lives, with row and column policy designed to apply at the query edge, which suits consortia whose agreements keep participant-level data at the collecting institution.

    Visit SemanticFedAll concepts

  • PlanMagnet

    Award aims, milestones and reporting dates

    Milestones, timelines and capacity-aware planning map naturally to specific aims and funder deliverables, and its CrewFoundry capacity integration keeps the plan honest about people.

    Visit PlanMagnetAll concepts

  • CrewFoundry

    People, effort allocation and training records

    People-to-project allocation, onboarding, learning paths and certificates, with utilization heatmaps on its roadmap, fit a lab's rotating workforce of students, postdocs and staff scientists moving between awards and instruments.

    Visit CrewFoundryAll concepts

  • VibeControls

    Persistent sessions for long-running analysis

    Persistent terminal sessions and scheduled jobs on machines the lab already owns suit students and research software engineers running multi-day jobs on clusters and workstations.

    Visit VibeControlsAll concepts

  • AdapterCloud

    Compute inventory and spend attribution

    One inventory and cost ledger across cloud accounts and Kubernetes clusters, extendable to campus systems through custom adapters, is designed to attribute spend to labs and awards and flag idle resources.

    Visit AdapterCloudAll concepts

  • AssetHandler

    Instrument calibration, maintenance and work orders

    Preventive maintenance plans, work orders and asset records with full history give core facilities a disciplined calibration and service cadence for expensive shared instruments.

    Visit AssetHandlerAll concepts

One platform underneath: Burdenoff Workspaces

Burdenoff Workspaces is the shared foundation: one sign-on for students, staff and partner investigators, role-based access that follows people across every product, one audit trail for grants, signatures and access decisions, and one bill across the products you adopt.

Concept gallery

Every concept in this solution

15 concepts from 8 products. Each one links to its own page on the product's website, and every view has a link you can share.

Pitch kit

The Science & Research solution in one minute

Research runs on disconnected tools, and it shows: figures nobody can rebuild, data shared by email, progress reports pieced together from spreadsheets, idle GPUs and instruments that fail mid-booking. Burdenoff brings LabsOfScience, CosmicIntersection, SemanticFed, PlanMagnet, CrewFoundry, VibeControls, AdapterCloud and AssetHandler onto one workspace, designed so the result, the data, the people, the compute and the grant connect. A pre-launch solution concept for research groups.

  • Designed to trace any figure to its source run, dataset version and frozen protocol, then publish a release with a DOI-style persistent identifier.
  • Share consortium data through scoped, expiring grants, designed to query partner sites in place with sensitive fields held back by approved policy.
  • Track specific aims and deliverables against real team capacity, so progress reports are designed to be compiled, not reconstructed.
  • Designed to attribute cluster and cloud compute to labs and awards and flag idle resources, with long jobs kept alive in persistent sessions.
  • Keep shared instruments calibrated and notify affected bookings in one step, with operator training checked before booking.
Email it

Questions

Frequently asked

Is this one product or several?

Several. Each product does one part of the job: LabsOfScience for the bench record, CosmicIntersection for data and releases, SemanticFed for federated queries, PlanMagnet for awards, CrewFoundry for people and training, VibeControls for long-running sessions, AdapterCloud for compute spend and AssetHandler for instruments. They share Burdenoff Workspaces for identity, access control, audit and billing, and you can start with the two or three that address your most urgent problem.

Does this replace our sponsored-programs, finance or payroll system?

No. Your institution's systems of record for awards, budgets and payroll stay where they are. PlanMagnet, CrewFoundry and AdapterCloud are designed to give PIs and research administrators a working view of aims, milestones, effort and compute burn, and anything compiled for a funder is meant to be reconciled with those official systems.

Can participant-level data stay at each partner institution?

That is the design intent of the federated approach. SemanticFed is designed to push queries down to each site's own database and return aggregates, with column policy and a minimum cell size applied at the query edge, while CosmicIntersection records who was granted access, why and until when. Whether a particular setup satisfies a specific data use agreement or IRB approval is a decision for your data steward and IRB.

Does this make our lab records compliant with electronic-records or research-integrity rules?

No product here guarantees compliance. LabsOfScience is designed around signed and witnessed notebook entries, frozen protocol versions and immutable dataset versions, and the platform records an audit trail of actions across the products you use. These are building blocks your quality, compliance and research-integrity teams can evaluate against the rules that apply to you.

Will it work with our existing cluster, cloud accounts and instruments?

AdapterCloud is built around an adapter model for cloud accounts, Kubernetes, on-premises systems and custom connectors, and VibeControls runs agents on machines you already own. In LabsOfScience, instruments are designed to be registered and booked as shared records, with calibration and service history held in AssetHandler; direct instrument data capture is on the LabsOfScience roadmap. A scoping conversation is the best way to map your estate.

Is this available today?

These products are pre-launch. This page describes a solution concept and how the products are designed to work together; individual capabilities are at different stages, and each product's own site shows what is available now. A pilot scoped to one lab or one core facility is a good place to start.

Related domains

Where these products also work together

All domains

Want to explore this for your organization?

Tell us about your setup. We will walk you through the products involved and scope a pilot around the challenge that hurts most.

Talk to usBrowse every domain

This is a solution concept: it shows how Burdenoff products are designed to work together in this industry. The images are illustrations of the concepts, not screenshots of the actual products, and every name and figure in them is sample data.