Industry solution

Space & Earth Observation

From tasking request to citable archive, one traceable path for every observation

Tasking, ground segment, pipelines, calibration and archive access designed to work as one system for Earth and space observation teams.

Products
8
Challenges
6
Concepts
15
Talk to us about Space & EOAsk a question
Ground-station dish at dusk tracking a satellite pass above a river floodplain
CosmicIntersection(opens CosmicIntersection in a new tab)IntelWatchtower(opens IntelWatchtower in a new tab)AssetHandler(opens AssetHandler in a new tab)AdapterCloud(opens AdapterCloud in a new tab)EcoImpactHub(opens EcoImpactHub in a new tab)LabsOfScience(opens LabsOfScience in a new tab)FluidGrids(opens FluidGrids in a new tab)BigConsole(opens BigConsole in a new tab)

The problem

Why the path from photons to decisions is hard to run

Observation teams run a chain of disconnected tools, so missed passes, stalled runs, untraceable calibrations and unconfirmed alerts surface late, and small teams spend their days reconstructing what happened.

Missions, observatories and remote-sensing centers run a chain in which every link belongs to a different team and a different tool. Tasking lives in email and spreadsheets, the ground station in vendor consoles, processing in scripts and schedulers, calibration in a scientist's notebooks, the archive in folders and a catalog, and partner delivery in attachments. Each link works on its own; the chain rarely does.

The pressure is structural. A pass cannot be repeated on the same orbit, so a missed contact or a stalled run is data lost, not merely delayed. Instruments drift over a mission's life, so a calibration update ripples through years of archive. And more users are operational, such as flood managers, conservation teams and public agencies, who need products inside a decision window and need to know how far to trust them.

Governance adds its own weight: proprietary periods and embargoes, open-data commitments, licenses, and the reproducibility that reviewers and funders expect. Most teams meet these by hand, so their most experienced people spend their best hours reconstructing what happened instead of improving what happens next.

Who this is for

  • Head of mission data systems

    Pass-to-product latency, pipeline failures caught before partners notice, and one traceable path from downlink to delivered product.

  • Ground-station and operations engineer

    Antenna and receive-chain health, maintenance that never lands on a protected pass, and fewer degraded or lost contacts.

  • Mission planner and tasking lead

    Ranking competing acquisition requests against pass windows and cloud risk, and proof that each partner requirement was satisfied.

  • Calibration and validation scientist

    Versioned coefficients, traceable reprocessing, and knowing exactly which products and releases each calibration touched.

  • Archive and data manager

    Proprietary periods and embargoes enforced through expiring grants, open data that flows without waiting, and citable releases.

  • Partner applications lead

    Change alerts partners can act on, field confirmation that flows back to analysts, and a monitoring service partners trust.

A day in the life

The story behind the solution

A week between the downlink and the decision

Leila Haddad runs mission data systems at Larkspur Earth Observation Center, which flies two small optical satellites, LK-1 and LK-2, operates its own X-band ground station and keeps a public imagery archive. This week a spring flood is building in a partner's river basin, the calibration team has news about the blue band, and the archive inbox is full.

  1. Tuesday, 07:40

    The pass that never became a product

    Leila is on her first coffee when the river basin authority emails to ask where this morning's flood scenes are. She has no answer. Her data engineer, Tomasz Wójcik, spends the next hour working out that a run stalled overnight and that nobody was told. Leila replies with an apology and no delivery time.

    How this is solved: Overnight passes that miss the delivery window

  2. Tuesday, 09:15

    Two late tracks and a firmware update

    Rohan Pillai, the station engineer, stops by Leila's office with a printout. The antenna has tracked late twice this week, and he has just noticed that the vendor's firmware update lands on Thursday's protected floodplain pass. Leila asks what else the update touches. Rohan says he will have to ask three people.

    How this is solved: Ground-station faults that quietly cost passes

  3. Wednesday, 11:00

    Three requests, two satellites

    The basin authority, a conservation partner and Leila's own calibration team all want time on the same two satellites this month. Her mission planner, Amara Nwosu, calls it a spreadsheet problem. When the basin authority phones to ask whether Monday's attempt worked, Leila puts them on hold and still cannot say.

    How this is solved: Acquisition requests competing in an inbox

  4. Wednesday, 16:20

    212 hectares of new water, probably

    The analysts are pleased: the change-detection run has found the flood. Leila is less sure what happens next. The partner's field lead calls to ask whether the blue patches are water or cloud shadow, and whether anyone wants to hear what his officers see on the ground. Leila realizes nobody has ever asked.

    How this is solved: Change alerts nobody confirms on the ground

  5. Thursday, 14:30

    The blue band has drifted

    Dr. Ingrid Solberg closes her laptop and says it plainly: LK-1's blue band has drifted, and eighteen months of products used the old coefficients. Leila's first question is which releases are affected. Her second arrives from finance an hour later: what will reprocessing cost, and can she say by Monday. She cannot answer either yet.

    How this is solved: A calibration update that ripples through the archive

  6. Friday, 16:45

    A request inside a proprietary period

    As Leila packs up, her data manager, Mateo Reyes, forwards a doctoral student's request for scenes still inside a partner's proprietary period and asks who can approve it before the weekend. It reminds Leila of the funder's question from Monday: how many papers use the center's archive? Nobody knows, because nobody can cite it.

    How this is solved: Data requests, proprietary periods and uncitable archives

None of these moments calls for a bigger team. They call for the request, the antenna, the pipeline, the field check, the calibration and the archive to share one record, so Leila's Monday review starts from what actually happened. That shared record is what the products on this page are designed to provide together.

Challenges and how they are solved

6 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 6

Overnight passes that miss the delivery window

CosmicIntersection(opens CosmicIntersection in a new tab)FluidGrids(opens FluidGrids in a new tab)BigConsole(opens BigConsole in a new tab)

The problem

At 02:47 LK-2 closes a clean pass over the station and the Level-0 files land on time. The Level-1C run then stalls at orthorectification, waiting for the restituted orbit and attitude file from flight dynamics, which has not arrived, and eventually fails. Nothing pages anyone: the error sits in a processing log, the ground-station report says the pass was fine, and the scheduler shows a run that simply stopped. At 07:40 the river basin authority asks where the morning flood scenes are. A data engineer spends the next hour stitching the story together from three consoles and a chat thread, and the weekly latency figure leadership asks for is still assembled by hand.

What it costs

Operational partners lose trust when products miss their decision window, and engineers spend mornings reconstructing failures instead of preventing the next one.

How the products work together

CosmicIntersection holds the Level-0 to Level-2 processing as a versioned pipeline triggered on ingest, and every run records its steps, inputs, parameters and errors, so the stalled orthorectification step and its missing orbit and attitude input are explicit. CosmicIntersection's run notifications are designed to call a FluidGrids webhook trigger. On failure the workflow waits, rechecks for the orbit and attitude file, starts a fresh run through the pipeline's webhook trigger, pages the on-call data engineer if that run fails too, and sends the partner a short status note. On every pass FluidGrids writes sensing, downlink and delivery timestamps to a keyed datasink, and BigConsole, which is built to read FluidGrids datasinks, is designed to turn them into a pass-to-product latency console that marks threshold breaches, with alert delivery on its roadmap, so the morning review opens on the breach and its cause.

The outcome it is designed for

Every pass is designed to have a visible path from downlink to delivered product, failures reach a person before partners notice, and latency becomes a live figure instead of a weekly spreadsheet.

The concepts behind it

Challenge 2 of 6

Ground-station faults that quietly cost passes

AssetHandler(opens AssetHandler in a new tab)AdapterCloud(opens AdapterCloud in a new tab)CosmicIntersection(opens CosmicIntersection in a new tab)IntelWatchtower(opens IntelWatchtower in a new tab)

The problem

At 09:15 Rohan Pillai, the station engineer, sees that the 7.3-meter X-band antenna tracked late on two overnight passes. Elevation drive current has been creeping up for a week, but the preventive plan for bearings, radome and low-noise amplifier lives in his spreadsheet, and the corrective job is a note on the whiteboard. The processing team sees a downlink source marked degraded with no reason attached. Worse, a demodulator firmware update is penciled in for 02:30 Thursday, on top of the next protected floodplain pass, and nobody can say what else the update touches between the station and the processing cluster.

What it costs

A missed or degraded pass cannot be recollected on that orbit, and maintenance booked over a priority pass turns routine work into lost data.

How the products work together

AssetHandler keeps the antenna, drives, feed, amplifier, demodulator and front-end servers as assets with preventive plans, work orders and change records, and is designed to add condition readings from connected sensors, a planned capability. Its readiness board is designed to read the contact schedule exported from the station's scheduling system, mark the passes protected by IntelWatchtower tasking, and flag the firmware change that collides with one. Before the change is approved, AdapterCloud's topology is designed to show what the demodulator and the station's edge servers feed downstream, from the network link to the processing cluster and archive storage. AssetHandler is then designed to hand the resulting status to the downlink source in CosmicIntersection, so a degraded pass carries its work order number instead of a mystery.

The outcome it is designed for

Maintenance lands between passes rather than on them, equipment faults become work orders before they cost data, and data engineers can see why a pass was degraded.

The concepts behind it

Challenge 3 of 6

Acquisition requests competing in an inbox

IntelWatchtower(opens IntelWatchtower in a new tab)CosmicIntersection(opens CosmicIntersection in a new tab)AssetHandler(opens AssetHandler in a new tab)

The problem

Wednesday at 11:00 the requests collide. The river basin authority wants a daily look at a 40-kilometer floodplain for three weeks. A conservation partner needs a cloud-free wetland mosaic before month end. The calibration team needs its desert-site overpass. Each arrived by email or phone, and the mission planner reconciles them in a spreadsheet against pass predictions and pointing limits. When the basin authority asks whether Monday's attempt worked, nobody can quickly say whether it was collected, clouded out or never tasked, or notice that Thursday's slot clashes with ground-station maintenance.

What it costs

Priorities are set by whoever wrote last, clouded-out attempts go unrecorded, and partners cannot see whether their need is being worked.

How the products work together

IntelWatchtower's collection-requirement model fits this loop: each partner need becomes a requirement with a priority, a due date and an owning mission for the partner's campaign, and each attempt becomes a tasking order against LK-1 or LK-2 with its window, status and a result summary such as collected or clouded out. The tasking planner is designed to show pass windows imported from the mission's planning and flight-dynamics tools, with their off-nadir angle and cloud outlook, beside each requirement's priority and due date, and to read AssetHandler's maintenance schedule so a clash is flagged before an order goes out. Collected scenes are designed to land in the partner's campaign collection in CosmicIntersection, and a requirement is marked satisfied only once the product exists there.

The outcome it is designed for

Every partner request has a status anyone can read, conflicts surface before an order goes out, and the question of whether a look was collected has a one-line answer.

The concepts behind it

IntelWatchtower

Satellite Tasking Requests and Pass Windows

Lays partner requirements, by priority and due date, beside pass windows imported from mission planning, and flags tasking that clashes with ground-station work.

Works with AssetHandler, CosmicIntersection

Concept pagefor Satellite Tasking Requests and Pass Windows on the IntelWatchtower website (opens in a new tab)

Challenge 4 of 6

Change alerts nobody confirms on the ground

CosmicIntersection(opens CosmicIntersection in a new tab)EcoImpactHub(opens EcoImpactHub in a new tab)FluidGrids(opens FluidGrids in a new tab)IntelWatchtower(opens IntelWatchtower in a new tab)

The problem

On Wednesday afternoon the change-detection notebook flags 212 hectares of new open water in the floodplain and a 6-hectare clearing inside the wetland buffer. The results leave as a shapefile attached to an email. The partner's field officers cannot tell flood from cloud shadow or seasonal paddy from the file alone, and when they check a spot a week later the answer comes back by phone and is never recorded. The analysts cannot say how often their detections hold up, and the requirement behind the monitoring still shows as open.

What it costs

Unconfirmed alerts erode trust both ways: partners stop acting on them, and the analysis team never learns which detections were wrong.

How the products work together

CosmicIntersection runs change detection as an analysis over the Level-2 datasets, marking it as machine-assisted and recording method, parameters and detected changes for an analyst to review. Reviewed change layers are designed to land in EcoImpactHub as satellite-sourced measurements on the partner's monitored sites, where site thresholds, such as open water above the seasonal baseline, raise alerts. Field officers are designed to check each alert against river gauge readings or a GPS-tagged photo from EcoImpactHub's planned field app and mark it confirmed, dismissed or needing a revisit. A FluidGrids workflow is designed to carry that verdict back to the IntelWatchtower requirement behind the monitoring, where it becomes validation data the analysts can query.

The outcome it is designed for

Partners receive alerts tied to their own sites, every detection is designed to end with a recorded verdict, and analysts build a validation record instead of relying on anecdote.

The concepts behind it

Challenge 5 of 6

A calibration update that ripples through the archive

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

The problem

Thursday at 14:30 Dr. Ingrid Solberg shares her analysis of the latest vicarious calibration campaign at a desert reference site: LK-1's blue band has drifted, and new gain coefficients are needed. The current coefficients live in a spreadsheet passed around by email, and eighteen months of Level-1 and Level-2 products were made with them. Nobody can list which collections and published releases are affected, the reprocessing will run for weeks on rented compute, and the finance office wants a number by Monday.

What it costs

Without a traceable link from coefficients to products, users cannot tell which data to trust, reprocessing is scoped by guesswork, and compute spend arrives as a surprise.

How the products work together

LabsOfScience records the calibration campaign as an experiment with runs, a signed and witnessed notebook entry and a frozen protocol, and publishes the new coefficients as an immutable, checksummed dataset version. CosmicIntersection's pipeline is designed to pin that version in its calibrate step, and its lineage answers which datasets, collections and releases were made with the previous one. The reprocessing tracker is designed to turn that answer into date-range batches, follow each run and list the releases that will need a new version. AdapterCloud records processing and storage spend against the cluster and archive resources the campaign's runs use, and is designed to show it per campaign; tag-based attribution and anomaly alerts are on its roadmap. The tracker is designed to estimate the remaining cost from compute hours per completed batch, so finance has a working figure to discuss.

The outcome it is designed for

Every product names the calibration it used, reprocessing is scoped from lineage rather than memory, and recorded spend and an estimate to finish sit beside the campaign's progress.

The concepts behind it

Challenge 6 of 6

Data requests, proprietary periods and uncitable archives

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

The problem

Friday at 16:45 a doctoral student at a partner university asks for scenes from a campaign still inside the partner's proprietary period. The request lands in a shared mailbox; the data manager checks a spreadsheet of agreements, then emails a download link that never expires. Open-data requests wait in the same queue as restricted ones. Meanwhile the annual surface-reflectance collection sits in a folder with a readme, and papers cite it as data courtesy of the center, so its use is invisible to funders. Observatory archives know the same pattern from proposal proprietary periods.

What it costs

Restricted data leaks through links that never expire, legitimate users wait days, and the archive's scientific value goes uncounted because it cannot be cited.

How the products work together

A FluidGrids form trigger takes each data request, and FluidGrids is designed to route it through a versioned decision-rule tree that encodes the data policy: requester type, campaign, proprietary period end date and license. Open data is approved straight away, restricted requests go to the data manager, and out-of-policy requests are declined with a reason. Approved requests are designed to become scoped access grants in CosmicIntersection, with a recorded reason and an expiry aligned to the proprietary period, revocable at any time and visible in the audit trail. When a collection is complete, CosmicIntersection bundles its datasets and the notebook that produced them into a versioned, licensed release with a DOI-style identifier, and a person makes the publish call.

The outcome it is designed for

Open data flows without waiting, restricted data opens and closes on schedule, and every finished collection can be cited and credited.

The concepts behind it

How it fits together

How one partner request moves through the products

Follow a flood-monitoring request from the partner's ask to a confirmed change alert and the delivery record behind it. Each step is one product doing one job, and shows how the products are designed to hand off.

  1. To AssetHandler: Protected pass windows, so ground-station work is booked around them.

  2. To CosmicIntersection: Ground-station status on the downlink source, so a degraded pass carries its reason.

  3. To CosmicIntersection: The coefficient version the pipeline pins in its calibrate step.

  4. To EcoImpactHub: Reviewed change layers as satellite-sourced measurements on the partner's monitored sites.

  5. To FluidGrids: A verdict for each alert, with its evidence attached.

  6. To BigConsole: Pass timings, run outcomes and verdicts written to keyed datasinks.

  7. To AdapterCloud: Passes whose delay traces to processing, so the estate behind them can be checked.

Step 1 of 8: Take the request

Products in this solution

What each product brings

  • CosmicIntersection

    Catalog, pipelines, lineage and releases

    Holds sources, datasets, versioned processing pipelines with per-step lineage, reviewed analyses, scoped access grants and citable releases: the spine the other products hand data to or read from.

    Visit CosmicIntersectionAll concepts

  • IntelWatchtower

    Acquisition requests and tasking

    Its collection-requirement and tasking model turns partner needs into prioritized requirements, tasking orders with windows and results, and a clear satisfied-or-not record.

    Visit IntelWatchtowerAll concepts

  • AssetHandler

    Ground-station assets and maintenance

    Keeps antennas, drives, receivers and station servers as assets with preventive plans, work orders and change records, with condition monitoring planned, so maintenance respects the contact schedule.

    Visit AssetHandlerAll concepts

  • AdapterCloud

    Ground-to-cloud estate and spend

    Maps station servers, network links, processing clusters and archive storage into one topology, and records compute and storage spend against the resources missions use.

    Visit AdapterCloudAll concepts

  • EcoImpactHub

    Partner sites and field confirmation

    Anchors satellite-derived change to monitored sites with thresholds, and is designed to give partner field officers a mobile way, through its planned field app, to confirm or dismiss each alert with evidence.

    Visit EcoImpactHubAll concepts

  • LabsOfScience

    Calibration campaigns and coefficients

    Records calibration campaigns in a signed notebook with frozen protocols, and publishes coefficient sets as immutable, checksummed dataset versions a pipeline can pin.

    Visit LabsOfScienceAll concepts

  • FluidGrids

    Automation between the steps

    Is designed to route run outcomes, alert verdicts and data requests through workflows and decision rules, and to feed BigConsole datasinks with pass and delivery metrics.

    Visit FluidGridsAll concepts

  • BigConsole

    Mission operations console

    Is designed to turn FluidGrids datasinks into a pass-to-product latency console for the morning operations review, with threshold alert rules on its roadmap.

    Visit BigConsoleAll concepts

One platform underneath: Burdenoff Workspaces

Burdenoff Workspaces is the shared foundation: one sign-on for station engineers, scientists, partners and guest researchers, role-based access per product and campaign, one audit trail across every request, run, grant and release, and one bill.

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 Space & EO solution in one minute

Missions, observatories and remote-sensing centers lose data and trust in the gaps between tools. Burdenoff is designed to connect the links on one workspace: IntelWatchtower for requests and tasking, AssetHandler and AdapterCloud for the ground segment, CosmicIntersection for pipelines, lineage and citable releases, LabsOfScience for calibration, EcoImpactHub for field confirmation, and FluidGrids with BigConsole to route outcomes and watch delivery.

  • Every pass traced from downlink to delivered product, with failed runs designed to reach a person before partners notice
  • Ground-station maintenance and changes planned around protected passes, with asset condition and work orders in one place
  • Partner requests tracked from requirement to tasked acquisition to field-confirmed change alert
  • Calibration coefficients versioned and pinned, so reprocessing is scoped from lineage, with recorded spend and an estimate to finish
  • Proprietary periods enforced through expiring grants, and finished collections published as citable releases
Email it

Questions

Frequently asked

Is this a live, integrated product today?

No. This page describes a solution concept. The products are pre-launch or in early access, and most hand-offs shown here describe how the products are designed to work together rather than out-of-the-box integrations. FluidGrids datasinks feeding BigConsole is part of both products' documented design. The other connections are designs, not built integrations; each would be configured, for example through FluidGrids webhooks, and scoped with you.

Does this replace our ground-station software or flight dynamics tools?

No. Antenna control, contact scheduling engines and flight dynamics stay where they are. AssetHandler tracks the station's equipment, maintenance and changes, IntelWatchtower tracks requests and tasking decisions, and CosmicIntersection records what the pipelines did. The aim is one record around your existing systems, not a replacement for them.

Can observatories and astronomy survey teams use the same setup?

The pattern carries over. Observing proposals map to requirements and tasking, telescope, dome and instrument equipment to AssetHandler assets, reduction pipelines and calibration frames to CosmicIntersection and LabsOfScience, and proposal proprietary periods to time-limited access grants and embargoed datasets.

Can processing stay on our own clusters or cloud accounts?

That is the design intent. CosmicIntersection is built to catalog datasets and record pipeline runs with their inputs and outputs, and dedicated tenancy or self-hosting is an Enterprise option. AdapterCloud is built to map on-premises, edge and cloud resources into one inventory and record their spend. How processing on your own clusters reports its runs into CosmicIntersection would be scoped with you.

How are restricted and embargoed datasets protected?

Datasets in CosmicIntersection carry an access level: public, workspace, restricted or embargoed. Restricted data is shared through scoped grants with a reason and an expiry that can be revoked at any time, and every grant sits in the workspace audit trail. This supports your data policy; it does not by itself establish compliance with any agreement or regulation.

Are machine-assisted detections sent to partners automatically?

No. Change detection and other machine-assisted analyses are recorded as such, with method and parameters, and an analyst reviews results before they reach a partner. Field verdicts recorded in EcoImpactHub are then designed to show which detections held up on the ground.

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.