Defense & intelligence · Managed environment

Satellite/Geospatial Data Lake

Storage and processing for large imagery holdings, designed and run for your mission

Overview

What you are buying

Moraph designs, builds and operates a storage and processing environment for satellite imagery and other geospatial data, sized for the volume and throughput your programs need. Imagery is ingested, cataloged and tiered so analysts and analytic jobs can reach it, and the compute your teams use for change-detection models sits next to the data. Your organization decides what is stored, who can see it and which analytic results are acted on; Moraph runs the environment under your authority.

The problem it solves

Geospatial programs collect imagery faster than general-purpose storage and IT teams can absorb it. Files arrive from several sources in different formats, catalogs drift out of date, and analysts wait for data to be copied to where their tools and models can reach it. Storage is expanded in emergencies rather than planned, and when security staff ask who accessed a holding or how an environment is configured, the answer depends on whoever built it.

  • Ingest from multiple collection and commercial sources is handled by scripts few people understand
  • Imagery is hard to find because catalog metadata is incomplete or inconsistent
  • Analytic jobs compete for compute that sits far from the data
  • Capacity, configuration and access evidence are maintained by hand

Who uses it

  • Geospatial intelligence program offices and mission data owners
  • Imagery and geospatial analysts who search and exploit the holdings
  • Data engineers and data scientists who build ingest pipelines and analytic models
  • Information system security managers and authorizing officials responsible for the environment
  • Inspectors and auditors who review access and configuration

Requirements it supports

DoD Instruction 8510.01, Risk Management Framework for DoD SystemsCNSSI No. 1253, Security Categorization and Control Selection for National Security SystemsNIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and OrganizationsIntelligence Community Directive 503, IC Information Technology Systems Security Risk ManagementDoD Manual 5200.01, DoD Information Security ProgramExecutive Order 13526, Classified National Security Information

The product supports these requirements; meeting them remains your organization’s responsibility.

Responsibilities

Who is responsible for what

Moraph designs and runs the environment; the storage, compute and cloud services come from infrastructure providers under their own terms; your organization owns the data and the decisions about it.

AreaMoraphInfrastructure and cloud providersYour organization
Hardware, cloud services and licensingSizes the environment, supplies or resells hardware, software and cloud services where contracted, and manages renewalsSupply hardware, software and cloud services under their own terms and warrantiesApproves designs and capacity plans and funds them
Platform availabilityOperates storage, compute and pipelines and restores service after failuresKeep their hardware and cloud services available under their own commitmentsProvides facilities, power and network for on-premises deployments
ConfigurationBuilds and maintains the configuration baseline and checks for driftProvide the underlying service configuration optionsApproves the baseline and any changes to it
Identity and accessConnects your identity provider and applies role designNone beyond their own administrative access controlsApproves every access grant and runs access reviews
MonitoringMonitors health, capacity and security events and forwards logsMonitor their own infrastructure and servicesReviews escalated security events in your security operations
Incident responseResponds under the agreed runbooks and reports each incidentRespond to failures in their hardware or servicesLeads security incident decisions and any reporting to authorities
ChangesRaises, tests and applies approved changes in agreed windowsAnnounce changes to their servicesApproves or rejects changes through the ISSM
Patches and updatesTests and applies patches on the agreed schedulePublish patches and firmware for their productsAgrees the patch schedule and approves exceptions
Data and policy decisionsApplies the rules you setNoneDecides sources, access, handling, retention and use of analytic results
AuthorizationMaps controls and supplies evidence for your packageProvide their own compliance documentationYour authorizing official decides whether the environment may operate

See how it works

A short walkthrough

Illustrative screens of how Moraph runs the service, with fictional sample data. They are not screens of the platform itself, which belongs to its vendor.

  1. Step 1

    Onboarding tracker

    During implementation, each workstream and decision is tracked with an owner on both sides.

    WorkstreamMoraph ownerYour ownerStatus
    Intake forecasts and sizingSolution architectProgram officeComplete
    Security design and control mappingSecurity leadISSMIn review
    Storage and compute buildPlatform engineerFacilities leadIn progress
    Source A ingest pipelinePipeline engineerData engineerIn progress
    Source B ingest pipelinePipeline engineerData engineerWaiting on sample files
    Holdings migration planData leadData ownerNot started
    During implementation, each workstream and decision is tracked with an owner on both sides.
  2. Step 2

    Configuration baseline review

    The approved baseline is checked regularly, and any drift is reported to your ISSM with how it will be resolved.

    Baseline check · Example Program environment (fictional)

    Baseline version
    Fictional v14
    Components checked
    212
    Matching baseline
    209
    Drift found
    3 items
    Next check
    Scheduled

    Drift items

    • Storage node 07: audit log forwarding disabled after maintenance
    • Compute pool B: one host missing the latest approved image
    • Catalog service: session timeout differs from baseline
    The approved baseline is checked regularly, and any drift is reported to your ISSM with how it will be resolved.
  3. Step 3

    A change request

    Every planned change is raised, tested and approved by your ISSM before it is applied in an agreed window.

    CR-0841 · Add archive tier capacity

    1. Change raised with capacity forecast attachedMoraph service manager
    2. Impact and rollback plan reviewedMoraph platform engineer
    3. Change approved for maintenance windowISSM
    4. Capacity added and verifiedMoraph platform engineer
    5. Change closed; baseline updatedMoraph service manager
    Every planned change is raised, tested and approved by your ISSM before it is applied in an agreed window.
  4. Step 4

    Alert triage

    Platform alerts are triaged by Moraph engineers, and anything with a security dimension is escalated to your security staff.

    AlertComponentDescriptionSeverityOwnerStatus
    PA-3302Ingest pipeline 2Delivery from Source B incompleteMediumMoraph engineerInvestigating
    PA-3299Storage node 07Audit log forwarding stoppedHighMoraph engineerEscalated to ISSM
    PA-3295Compute pool AGPU queue above quota for 2 hoursLowService managerData owner informed
    PA-3290Archive tierCapacity above planning thresholdMediumService managerChange raised
    Platform alerts are triaged by Moraph engineers, and anything with a security dimension is escalated to your security staff.
  5. Step 5

    Monthly service review

    Each month Moraph reports on the service and agrees actions with your program office.

    Monthly service review · Fictional sample month

    Incidents
    2 (none open)
    Changes applied
    9 of 9 approved
    Patches applied
    On agreed schedule
    Storage used
    71% of current capacity
    Ingest rejections
    Source B above usual

    Actions agreed

    • Data engineer to confirm Source B format change with provider
    • Moraph to present archive expansion options
    • ISSM to schedule quarterly access review
    Each month Moraph reports on the service and agrees actions with your program office.
  6. Step 6

    Access review

    Data owners recertify who can see each collection, and access that is no longer needed is removed.

    UserCollectionApproved byLast usedDecision
    Analyst 0412 (fictional)Example Collection NorthData ownerThis weekKeep
    Analyst 0388 (fictional)Example Collection NorthData ownerNot used in review periodRemove
    Data engineer 0107 (fictional)Example Collection SouthData ownerThis monthKeep
    Analyst 0451 (fictional)Example Collection SouthData ownerLast monthPending
    Data owners recertify who can see each collection, and access that is no longer needed is removed.

Workflows

The principal workflows

  1. Ingest

    Imagery and associated metadata arrive from the sources your organization approves, are checked and cataloged, and land in the storage tier that matches how often they will be used.

    • New sources are registered with the data owner's approval and an agreed format
    • Files are checked for completeness and readable metadata on arrival
    • Catalog entries are created with footprint, collection time, sensor and handling markings supplied by the source
    • Data is written to the hot, warm or archive tier according to your rules
    • Failed or incomplete deliveries are flagged to the data engineer
  2. Find and process

    Analysts search the catalog by area, time and sensor, and analytic jobs, including change-detection models your teams choose, run on compute placed next to the storage.

    • Analyst searches by area of interest, date range and sensor
    • Results are limited to holdings the analyst is authorized to see
    • Data scientist submits a processing or model job against a selected set
    • Compute is allocated from the shared pool within the program's quota
    • Outputs are written back to the lake and cataloged with their lineage
  3. Review detections

    Model outputs are candidates, not conclusions. Each candidate change is queued for an analyst, who confirms or rejects it and records the reason.

    • Candidate changes appear in a review queue with before and after imagery
    • Analyst compares the scenes and any supporting holdings
    • Candidate confirmed, rejected or referred for further review, with a note
    • Confirmed items are exported to your reporting or exploitation tools
    • Rejection reasons are kept for model owners to review
  4. Operate

    Moraph monitors the environment, plans capacity, applies patches and approved changes, and reports on service and security each month.

    • Platform health, throughput and capacity monitored continuously
    • Alerts triaged and incidents handled under the agreed runbooks
    • Changes raised, reviewed by your security staff and applied in a window
    • Patches tested and applied on the schedule your ISSM agrees
    • Monthly service review covers capacity, incidents, changes and access

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

Mission data owner

Program manager, mission data steward, collection manager

Owns the holdings in the lake and makes the decisions about sources, access and retention.

Sees

  • Holdings, sources and catalog statistics for their programs
  • Access grants and pending requests for their collections
  • Capacity use and forecasts for their programs
  • Monthly service reports

Does

  • Approves new data sources and changes to existing ones
  • Approves or declines requests for access to their collections
  • Sets retention and tiering rules for their holdings
  • Agrees capacity plans and priorities with the program office
  • Reviews the monthly service report with Moraph

Cannot

  • Change platform configuration directly
  • Grant access outside the handling rules their organization sets
  • Delete audit records
Approvals
Approves sources, access to their collections and retention rules; their own access changes are applied by the ISSM.
Notified about
Access requests for their collections, failed deliveries from their sources, and capacity nearing agreed limits.

Data engineer

Data engineer, geospatial data manager, pipeline developer

Keeps imagery flowing from approved sources into the lake in a usable, cataloged form.

Sees

  • Ingest pipelines, their runs and their failures
  • Catalog rules and metadata quality results
  • Storage tiers and retention rules for their programs

Does

  • Defines the format and metadata expected from each source
  • Investigates failed or incomplete deliveries and arranges reprocessing
  • Maintains catalog rules and metadata mappings
  • Proposes tiering and retention rules for the data owner to approve
  • Runs processing jobs to prepare data for analysts

Cannot

  • Register a new source without data owner approval
  • Grant other users access to holdings
  • Change platform security configuration
Approvals
New sources and retention changes they propose go to the data owner; pipeline changes that affect the platform are raised as change requests.
Notified about
Failed ingest runs, metadata quality failures and decisions on their proposals.

Analyst

Imagery analyst, geospatial analyst, all-source analyst

Uses the holdings and analytic outputs to answer mission questions, and is the person who decides whether a candidate detection is real.

Sees

  • Catalog search results for holdings they are authorized to see
  • Imagery and derived products within their grants
  • Candidate detections queued for their area or program
  • Lineage of any derived product they open

Does

  • Searches by area, time and sensor and retrieves imagery
  • Submits processing jobs within the program's quota
  • Confirms, rejects or refers candidate detections with a recorded reason
  • Exports confirmed items to their reporting or exploitation tools
  • Requests access to additional collections

Cannot

  • See holdings outside their grants
  • Change models, pipelines or retention rules
  • Delete imagery or derived products
Approvals
Access to additional collections is approved by the data owner and applied by the ISSM.
Notified about
New candidates in their review queue, completed jobs and decisions on access requests.

ISSM

Information system security manager, ISSO, security control assessor liaison

Answers for the security of the environment and controls what changes are made to it.

Sees

  • The configuration baseline and any drift from it
  • Change requests, patches and their status
  • Access grants, privileged accounts and audit logs
  • Control mappings and evidence for the RMF package

Does

  • Approves or rejects configuration changes and patch schedules
  • Applies access grants approved by data owners
  • Reviews audit logs and security alerts escalated by Moraph
  • Runs periodic access reviews
  • Prepares continuous monitoring submissions with the evidence Moraph supplies

Cannot

  • Approve a change they raised themselves without a second approver
  • Edit or delete audit records
  • Grant access to a collection without the data owner's approval
Approvals
Approves changes, patch schedules and security exceptions; access grants require data owner approval first.
Notified about
Change requests awaiting approval, security alerts, configuration drift and access reviews coming due.

Moraph platform engineer

Moraph storage, compute and pipeline engineers (US citizens with the clearances the contract requires)

Keeps the environment running: storage, compute, networking inside the boundary, pipelines and monitoring.

Sees

  • Platform health, capacity and performance
  • Pipeline runs and errors, without opening the imagery itself
  • Platform logs and alerts
  • Approved change requests and maintenance windows

Does

  • Monitors the platform and triages alerts
  • Applies approved changes and patches in agreed windows
  • Expands storage and compute under approved capacity plans
  • Handles incidents under the agreed runbooks and reports them
  • Restores service and data from backups when required

Cannot

  • Open or search mission imagery or analytic outputs
  • Grant access to holdings
  • Make a change that has not been approved, except emergency actions recorded and reviewed under the incident process
Approvals
Every planned change is approved by the ISSM; emergency actions are reported to the ISSM and reviewed afterwards.
Notified about
Platform alerts, capacity thresholds, approved changes scheduled and incidents.

Moraph service manager

Moraph service delivery manager

Is the single point of accountability for the service, and runs the monthly service review.

Sees

  • Service performance, incidents and open problems
  • Change and patch calendars
  • Capacity use and forecasts
  • Open requests from your organization

Does

  • Runs the monthly service review and agrees actions
  • Coordinates change requests between your teams and Moraph engineers
  • Tracks capacity plans and raises expansion needs early
  • Manages escalations to infrastructure providers

Cannot

  • Open mission content
  • Approve changes on your organization's behalf
  • Grant access to holdings
Approvals
Nothing they do changes the environment without ISSM approval.
Notified about
Major incidents, escalations, overdue changes and capacity forecasts that need a decision.

Auditor (read-only)

Inspector general staff, security control assessor, internal auditor

Reviews how the environment is configured and who has accessed what, without being able to change anything.

Sees

  • Access grants and access review results
  • Configuration baseline, changes and patch history
  • Audit logs within the scope granted
  • Control evidence and service reports

Does

  • Searches and reads records within their scope
  • Exports records and reports, with each export logged
  • Records review notes where enabled

Cannot

  • Change, approve or delete anything
  • See mission content unless separately granted
  • Keep access after it expires
Approvals
Their access is approved by the ISSM with a scope and an end date.
Notified about
Nothing by default; access granted and expiring is confirmed to the ISSM.

Permissions at a glance

ActionData ownerData engineerAnalystISSMMoraph eng.Service mgrAuditor
Register a new data sourceApprovesOwn work onlyNo accessView onlyFullView onlyNo access
Run and monitor ingest pipelinesView onlyOwn work onlyNo accessNo accessFullView onlyNo access
Search and retrieve imageryFullOwn work onlyOwn work onlyNo accessNo accessNo accessNo access
Run processing and model jobsView onlyOwn work onlyOwn work onlyNo accessNo accessNo accessNo access
Confirm or reject candidate detectionsView onlyNo accessOwn work onlyNo accessNo accessNo accessView only
Set retention and tiering rulesApprovesOwn work onlyNo accessView onlyFullView onlyView only
Grant access to collectionsApprovesNo accessNo accessFullNo accessNo accessView only
Change platform configurationNo accessNo accessNo accessApprovesOwn work onlyView onlyView only
Apply patches and updatesNo accessNo accessNo accessApprovesFullView onlyView only
Triage platform alertsNo accessNo accessNo accessView onlyFullView onlyNo access
View audit logsView onlyNo accessNo accessFullView onlyNo accessView only
  • Full
  • Own work only
  • Approves
  • View only
  • No access

How access is controlled

  • Moraph engineers run the platform but do not open mission imagery or analytic outputs; their access is limited to the infrastructure and is recorded like everyone else's.
  • Nobody approves their own change: changes raised by Moraph or your staff are approved by the ISSM, and changes the ISSM raises need a second approver.
  • Roles are configured with you during design. Access can be limited by program, collection and handling marking, and follows the groups in your identity provider.
  • Work on federal and defense tickets is done only by US citizens holding the clearances the contract requires, and work in classified environments happens under your organization's authority.

Features

What it does

Tiered storage

Hot, warm and archive tiers with rules for when data moves between them, so frequently used imagery stays close to analysts and older holdings cost less to keep.

Managed ingest pipelines

Pipelines for each approved source, with checks on arrival and a record of every file received, rejected or reprocessed.

Geospatial catalog

Search by footprint, time, sensor and other metadata, with results filtered by the searcher's access.

Compute next to the data

A shared pool of CPU and GPU compute for processing and model jobs, with quotas by program so one workload does not starve another.

Model hosting

Run the change-detection and object models your organization selects, with each run recorded against the model version and data used.

Analyst review queue

Model outputs are queued for analysts to confirm or reject, so no candidate detection is treated as a finding until a person decides.

Data lineage

Every derived product records the source imagery, processing steps and model version that produced it.

Access by holding

Access is granted per collection or program and follows the handling markings your organization assigns, with each grant recorded.

Capacity planning

Storage and compute use tracked against forecast intake, so expansion is planned with your program office rather than made in an emergency.

Configuration baseline

The approved configuration is documented and checked for drift, and differences are reported to your ISSM.

Retention rules

Retention and disposition rules set by the data owner are applied by tier and collection, with a record of what was removed and when.

Control evidence

Control mappings and evidence prepared for your RMF package and continuous monitoring, kept current as the environment changes.

Integrations

How it connects to your systems

Connects toHowWhat flows
Collection and commercial imagery sourcesFeeds from the government and licensed commercial sources your organization approves, by file transfer or provider API.In: imagery, metadata and handling markings supplied by each source.
Exploitation and GIS toolsAnalysts reach holdings from the tools they already use through standard geospatial services and file access.Out: imagery and derived products within each user's grants.
Model development environmentModels your data scientists build or select are registered and run on the lake's compute.In: model packages and versions. Out: candidate detections with lineage.
Cross-domain solutionWhere data must move between security domains, it goes through the cross-domain solution your organization has approved, not through the lake.In and out: transfers handled by your approved solution.
Identity providerUsers sign in through your organization's identity provider, including certificate-based sign-in where required.In: user identity, attributes and group membership for access.
Security monitoringPlatform and access logs forwarded to your security operations tooling.Out: audit, access and platform logs.
Moraph Work APIService tickets, change requests and service reports available to your service management tools.Out: tickets, changes and service metrics.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

Single sign-on

Users sign in through your identity provider, so your authentication policies, including certificate-based sign-in, apply.

Access by role and holding

What each person can see follows their role and their grants by program and collection; platform operators do not see mission content.

Encryption and keys

Data is encrypted at rest and in transit, with keys Moraph staff cannot use without explicit, time-bound authorization from your organization.

Complete audit trail

Every search, retrieval, grant, change and export is logged with the person and time, and cannot be edited.

Cleared US staff

Federal and defense work is handled only by US citizens with active clearances, and the environment is hosted only in the United States.

Tested releases

Security testing gates every change to Moraph's tooling, and a software bill of materials is kept for the components Moraph supplies.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

11 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Service

Monthly service review

For program office, data owners and ISSM

Availability, incidents, changes made, open problems, capacity use and actions agreed at the last review.

Break down by
Month, Service component, Incident severity, Action owner
Delivered as
PDF; review meeting
Used for
Holding Moraph to account for the service and agreeing priorities.

Incident log

For iSSM and program office

Each incident with its start, impact, actions taken, resolution and follow-up.

Break down by
Severity, Component, Cause category, Period
Delivered as
Live view; PDF and CSV export
Used for
Reviewing how incidents were handled and whether follow-up actions closed.

Change and patch record

For iSSM and auditors

Every change and patch with who raised, approved and applied it, the window used and the outcome.

Break down by
Change type, Approver, Component, Outcome
Delivered as
Live view; CSV export
Used for
Evidencing that the environment changes only through approved requests.

Open requests

For program office and service manager

Service requests and change requests open, their age and what each is waiting on.

Break down by
Request type, Requester, Age, Status
Delivered as
Live dashboard
Used for
Making sure no request stalls between teams.

Capacity and data

Capacity and forecast

For program office and data owners

Storage by tier and compute use against capacity, with forecast intake from planned sources.

Break down by
Tier, Program, Source, Month
Delivered as
Live dashboard; PDF for planning
Used for
Planning and funding expansion before capacity runs short.

Ingest health

For data engineers and data owners

Files received, rejected and reprocessed by source, with the reasons for rejection.

Break down by
Source, Reason, Day, Pipeline
Delivered as
Live dashboard; scheduled email
Used for
Fixing source and pipeline problems before analysts notice missing data.

Catalog completeness

For data engineers

Holdings with missing or inconsistent metadata that make them hard to find.

Break down by
Source, Missing field, Program
Delivered as
Live view; CSV export
Used for
Targeting metadata clean-up where it helps search most.

Detection review outcomes

For model owners and data owners

Candidate detections confirmed, rejected and referred by model version, with rejection reasons.

Break down by
Model version, Area, Outcome, Period
Delivered as
Live dashboard; CSV export
Used for
Deciding whether a model is useful enough to keep running and where it needs retraining.

Security and audit

Access review

For iSSM and data owners

Each user's grants by collection, when they were approved, and when they were last used.

Break down by
Collection, User, Approver, Last use
Delivered as
Live view; PDF and CSV export
Used for
Periodic recertification and removing access that is no longer needed.

Configuration baseline and drift

For iSSM and assessors

The approved configuration, any differences found on the latest check, and how each was resolved.

Break down by
Component, Control family, Drift status
Delivered as
Live view; PDF export
Used for
Continuous monitoring and assessment evidence.

Audit trail extract

For iSSM, inspectors and auditors

Who searched, retrieved, granted, changed or exported what, and when, for a selected holding, user or period.

Break down by
Holding, User, Action, Date range
Delivered as
On request; CSV and PDF export
Used for
Answering inspection and investigation requests without assembling logs by hand.

Exports, access and evidence

  • Reports can be exported to CSV and summary reports to PDF, and scheduled to the people entitled to see them.
  • Reports respect each viewer's role and grants: a data owner sees their programs, the ISSM sees the environment, and Moraph staff see service and platform data without mission content.
  • Service tickets, changes and metrics are available through the Moraph Work API for your own service management and reporting tools.
  • Audit and access reports can be run as of a past date and give the same result each time; running and exporting a report is itself logged.
  • In classified deployments, reports are produced and kept inside the environment and leave it only through your approved channels.

Deployment

Where and how it runs

On your premises

Built in your data center or enclave, including classified environments, and operated under your organization's authority by cleared Moraph staff where the contract provides for it.

US government cloud region

Built in a US government cloud region your organization has approved, hosted only in the United States.

Hybrid

A cloud or central archive combined with storage and compute closer to where data is collected, scoped in the proposal.

Security controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

Requirements and sizing

We work with your program office on sources, expected intake, retention, users and workloads, and size storage and compute from them. We need intake forecasts and a contact from each data source.

Architecture and security design

The environment is designed for your network and security domain, with the control mapping your ISSM needs for the RMF package.

Build

Storage, compute, catalog and monitoring are built and configured to the agreed baseline, on your premises or in a US government cloud region.

Pipelines and catalog

Ingest pipelines are built for each approved source, and catalog rules and metadata mappings agreed with your data engineers.

Migration and testing

Existing holdings are migrated in an agreed order, and ingest, search and processing are tested with your staff before cutover.

Authorization support and handover to operations

We supply evidence for your assessment, then move to steady-state operations with runbooks, reporting and the first service review.

Limitations

What it does not do

Worth knowing before you evaluate it.

  • Moraph is not the manufacturer of the storage and compute hardware or the cloud provider. Their own service commitments, roadmaps and outages apply, and hardware, software and cloud licences are subject to their terms.
  • Moraph does not hold an accreditation or authorization for the environment. Your authorizing official decides whether it operates; Moraph maps controls and supplies evidence to support that decision.
  • Work in classified environments happens under your organization's authority and only where the contract provides for it, by US citizens with the required clearances.
  • Moraph does not collect or task imagery. Data comes from the government and licensed commercial sources your organization provides, under their terms.
  • Model outputs are candidates for analysts to review, not findings. Choosing, validating and interpreting analytic models is your organization's responsibility.
  • Ingest and processing throughput depend on network links, hardware, data formats and workloads; they are sized during design rather than guaranteed in advance.
  • Moving data between security domains is not included; it uses the cross-domain solution your organization has approved.
  • The lake does not replace analysts' exploitation and GIS tools; it provides the storage, catalog and compute those tools draw on.

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

  1. Give us your intake forecast and retention rules and review the sizing and assumptions we return
  2. Ask how a new source is approved, built and monitored, and who is notified when deliveries fail
  3. Walk through a change request from raising it to ISSM approval and baseline update
  4. Confirm that Moraph engineers can operate the platform without access to mission content
  5. Review a sample monthly service report and control evidence package with your ISSM
  6. Check the responsibilities table against your own operating model and contract

Questions

Frequently asked questions

Who owns the data in the lake?

Your organization does. Moraph operates the environment and does not use or open mission content. Return and disposition of data at the end of the agreement are set out in the contract.

Can Moraph operate the environment at a classified level?

Where your contract provides for it, cleared Moraph staff operate environments in classified enclaves under your organization's authority. Moraph does not hold an accreditation of its own; your authorizing official decides whether the environment operates.

Which analytic models can we run?

The models your organization selects or builds, including change-detection models. Moraph provides and runs the compute; model choice, validation and interpretation stay with your teams.

Can it be built in the cloud?

Yes, in a US government cloud region your organization has approved, on your premises, or a combination. The choice is made during design.

How is it priced?

As a managed service, usually driven by the storage and compute provisioned and the scope of operations, with design and build charged separately and infrastructure passed through or supplied by you. See Working with Moraph for what drives a quotation.

Is there an accessibility conformance report?

Ask for one through the procurement request form at /how-to-buy/request, naming the components you are evaluating.

Next steps

Evaluate Satellite/Geospatial Data Lake

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: Satellite/Geospatial Data Lake guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: Satellite/Geospatial Data Lake support guide.