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 very first line. 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 cloud machine with a graphics processor (GPU) 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 remote connection 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.

Answers are in plain business terms. Choose Technical, or open any technical detail, to see how it works under the hood.

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 software setup, the exact tool 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

LabsOfScience keeps the bench record: every run, the protocol version it followed and each locked data version. CosmicIntersection keeps each figure's analysis with its exact software versions saved, so someone other than its author can re-run it. Before the lab replies to a reviewer, a figure report is designed to show which figures rebuild cleanly, which differ and which have no source; an approved release gets a citable reference.

How it works — technical detail

Technical detail

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 details, such as home addresses, dates of birth and survey ID numbers, 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 study data, 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, force a report to the institutional review board (IRB) and strain the partnership, while legitimate pooled analysis waits on hand-built extracts.

How the products work together

CosmicIntersection turns a partner's request into an access grant tied to the data use agreement, with a reason and an end date, instead of an email attachment. SemanticFed is designed to answer the pooled question inside each partner site's own records, so only totals come back. Names, addresses and survey ID numbers stay hidden under rules only the data steward can approve, and very small counts are held back.

How it works — technical detail

Technical detail

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, individual participant records stay at the site that collected them, and every access 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 principal investigator's (PI's) memory, effort in payroll spreadsheets that lag every change in appointment, and products such as data collections 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 lays out each specific aim as milestones, deliverables and funder reporting dates, with progress designed to come from LabsOfScience experiment records. CrewFoundry records who works on which award; a view on its roadmap is meant to show who is stretched across awards and where an open postdoc role leaves an aim short. The research administrator compiles the report from these records, then checks it against the institution's official systems.

How it works — technical detail

Technical detail

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. Cloud machines with graphics processors (GPUs) that were 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

Computing costs with no owner land 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 keeps long analysis runs going on lab workstations and, where the research computing team allows it, the campus cluster, so a closed laptop no longer ends a 40-hour run. AdapterCloud is designed to show cloud and cluster spending by lab and award and flag an idle cloud machine with the name of whoever started it, so the computing lead messages the right student. Nothing is switched off automatically.

How it works — technical detail

Technical detail

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 computing 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 keeps each instrument's calibration dates, service contract and work orders, so calibration is scheduled instead of remembered. When a check fails and a work order opens, the instrument is designed to show as under maintenance in LabsOfScience bookings, and the facility manager warns everyone affected in one step. CrewFoundry keeps training certificates, showing who can check the instrument after service and whether a new user may book.

How it works — technical detail

Technical detail

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, with one shared sign-in and one record of who did what. 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 computing it used.

  1. To CrewFoundry: Staff time each aim needs, checked against who is actually available

  2. To AssetHandler: The people currently trained to check an instrument after service

  3. To LabsOfScience: A service window that marks the instrument under maintenance for bookings

  4. To CosmicIntersection: Locked data versions, listed in the catalog for analysis and releases

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

  6. To CosmicIntersection: Pooled totals with sensitive details hidden, saved for a citable release

  7. To AdapterCloud: Which machines are running the work, labeled with lab and award

Step 1 of 8: Plan the award

How each hand-off works — technical detail

Technical detail

  1. 1. PlanMagnet — Plan the award: Turns the funded specific aims into milestones, deliverables and reporting dates on the award timeline.Hands to CrewFoundry: Staffing needs and effort per aim, weighed against real team capacity.
  2. 2. CrewFoundry — Staff and train the team: Allocates students, postdocs and staff to each award as a project, and holds onboarding, operator learning paths and certificates.Hands to AssetHandler: Operators with current instrument training, listed for verification after service.
  3. 3. AssetHandler — Keep instruments calibrated: Schedules calibration and preventive maintenance for shared instruments and opens a work order when a check fails.Hands to LabsOfScience: A service window that switches the linked instrument to under maintenance for the affected bookings.
  4. 4. LabsOfScience — Run and record the bench: Records experiments and auto-numbered runs under frozen protocol versions, and versions every dataset with a checksum.Hands to CosmicIntersection: Frozen dataset versions and checksums, registered in the catalog for notebooks and releases.
  5. 5. CosmicIntersection — Share data under agreement: Catalogs each site's datasets and grants partner investigators scoped, expiring access with a recorded reason.Hands to SemanticFed: An access grant tied to the data use agreement.
  6. 6. SemanticFed — Pool partner data in place: Is designed to answer consortium questions across partner sites' databases in place, with sensitive columns held back by approved policy.Hands to CosmicIntersection: Pooled, masked aggregates saved as a derived dataset, published with the notebook as a release with a DOI-style persistent identifier.
  7. 7. VibeControls — Run long analysis jobs: Holds model training and analysis in persistent terminal sessions on login nodes, lab workstations and cloud instances.Hands to AdapterCloud: Session hosts and instance ids, tagged with the lab and the award.
  8. 8. AdapterCloud — Attribute compute to grants: Attributes cluster and cloud spend to labs and awards, and is designed to flag idle or untagged resources for the PI to read directly.

Products in this solution

What each product brings

  • LabsOfScience

    Lab record: runs, protocols, data versions, instruments

    Signed notebook entries, frozen protocol versions, data versions that cannot be quietly changed and a booking calendar that prevents double-booking are all built around one goal: results that can be rebuilt later.

    Technical detail

    Technical detail

    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-heavy science beyond astronomy, it controls who can use shared data, keeps each analysis re-runnable, traces every result to its source and publishes citable releases, so shared data becomes work others can reuse and credit.

    Technical detail

    Technical detail

    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

    Pooled answers across partner sites' data

    It answers questions from data where it already sits, with rules on who sees which records and details designed to apply to every answer. That suits consortia whose agreements keep individual participant records at the institution that collected them.

    Technical detail

    Technical detail

    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 planning that accounts for staff time fit specific aims and funder deliverables naturally. Its link with CrewFoundry keeps the plan honest about who is actually available.

    Technical detail

    Technical detail

    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

    Assigning people to projects, onboarding, training paths and certificates, with a workload view on its roadmap, fit a lab where students, postdocs and staff scientists keep moving between awards and instruments.

    Technical detail

    Technical detail

    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

    Long-running analysis that survives a closed laptop

    Sessions that keep running after a laptop closes, plus scheduled jobs on machines the lab already owns, suit students and research software engineers running multi-day jobs on clusters and workstations.

    Technical detail

    Technical detail

    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

    Computing inventory and costs by lab and award

    It keeps one inventory and cost ledger across cloud accounts and computing clusters, can be extended to campus systems, and is designed to assign spending to labs and awards and flag idle machines.

    Technical detail

    Technical detail

    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

    Planned maintenance, work orders and a full history for every instrument give core facilities a steady calibration and service routine for expensive shared equipment.

    Technical detail

    Technical detail

    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 cloud machines 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 computing and the grant connect. A pre-launch solution concept for research groups.

  • Designed to trace any figure to its source run, data version and frozen protocol, then publish a citable release with a permanent reference.
  • Share consortium data through limited, expiring access grants, designed to answer questions inside each partner site's own records with sensitive details held back under approved rules.
  • Track specific aims and deliverables against real team capacity, so progress reports are designed to be compiled, not reconstructed.
  • Designed to assign cluster and cloud computing costs to labs and awards and flag idle machines, with long runs kept going after a laptop closes.
  • 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. Eight products each handle one part of the job, from the lab record and shared data to grants, people, computing and instruments. They share one sign-in, one set of permissions, one record of who did what and one bill, and you can start with the two or three that address your most urgent problem.

Technical detail

Technical detail

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 official systems for awards, budgets and payroll stay where they are. PlanMagnet, CrewFoundry and AdapterCloud are designed to give lab heads and research administrators a working view of aims, milestones, effort and computing costs, and anything sent to a funder is meant to be checked against those official systems.

Technical detail

Technical detail

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?

Yes, that is the design intent: SemanticFed answers each question inside each site's own records and returns only totals, with sensitive details and small counts held back, while CosmicIntersection records who has access, why and until when. Whether that satisfies a specific agreement or ethics approval is for your data steward and institutional review board to decide.

Technical detail

Technical detail

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. No product here guarantees compliance. LabsOfScience is designed around signed and witnessed notebook entries, locked protocol versions and data versions that cannot be changed, and the platform keeps a record of who did what across the products you use. Your quality, compliance and research-integrity teams can judge these against the rules that apply to you.

Technical detail

Technical detail

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?

Yes, that is the intent. AdapterCloud is built to connect cloud accounts, computing clusters and on-site systems, VibeControls runs on machines you already own, and instruments are designed to be booked in LabsOfScience with their service history in AssetHandler. Reading results straight off instruments is on the roadmap, and a scoping conversation is the best way to map your setup.

Technical detail

Technical detail

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?

No, not yet. These products are pre-launch, and this page describes how they are designed to work together. Individual capabilities are at different stages and each product's own site shows what is available now; a pilot with one lab or one core facility is a good place to start.

Technical detail

Technical detail

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.