Defense & intelligence · Managed service (Palantir Gotham)

Palantir "Gotham" Integration & Governance

Check the quality, lineage and markings of data before it reaches Palantir Gotham

Overview

What you are buying

Palantir "Gotham" Integration & Governance is a Moraph-managed service that builds and runs the data pipelines feeding your Palantir Gotham deployment. Each source is mapped, checked for completeness and consistency, traced from origin to ingestion, and checked for classification and handling markings before it is loaded. Records that fail a check are held for your data stewards and trained classifiers to decide on, so analysts work from data whose origin and markings can be shown.

The problem it solves

Analysis is only as good as the data behind it. When feeds are loaded into an analytic platform without consistent checks, duplicates, missing fields, mismatched identifiers and stale records flow straight into the picture analysts rely on. Classification and handling markings may be missing or inconsistent between sources, which risks both over-restriction and spillage. And when a finding is questioned, it can be hard to show where each piece of data came from and what was done to it on the way in.

  • Feeds arrive with duplicates, gaps and mismatched identifiers
  • Markings are missing or inconsistent between sources
  • The path from a source record to what an analyst sees is not documented
  • Pipelines built one at a time are hard to maintain and audit

Who uses it

  • Intelligence and defense organizations that run Palantir Gotham
  • Data owners and stewards responsible for the sources that feed it
  • Security and classification management staff responsible for markings
  • Analysts who need to trust and explain the data they work with
  • Oversight, compliance and inspector general staff who review data handling

Requirements it supports

Executive Order 13526, Classified National Security Information32 CFR Part 2001, Classified National Security Information (ISOO implementing directive)32 CFR Part 2002, Controlled Unclassified InformationDoD Manual 5200.01, Volume 2, Marking of InformationExecutive Order 12333, United States Intelligence ActivitiesPrivacy Act of 1974 (5 U.S.C. 552a)

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

Responsibilities

Who is responsible for what

Palantir provides and supports Gotham, Moraph builds and runs the pipelines and governance controls that feed it, and your organization owns the data, its classification and who may see it.

AreaMoraphPalantirYour organization
LicensingCoordinates Gotham licensing where Moraph resells it, or works with your existing licensesSets license terms and subscription scopeApproves the order and accepts Palantir's terms
Platform availabilityMonitors pipeline delivery into Gotham and raises cases with PalantirProvides, supports and updates Gotham under its own commitmentsProvides or authorizes the hosting environment
PipelinesDesigns, builds, runs and maintains the pipelines from each source into GothamProvides Gotham's data integration interfacesAuthorizes each source and provides access to it
Data quality rulesWrites and maintains the quality checks and reports failuresNoneApproves the rules and decides on held records through your data stewards
Classification and markingsChecks that required markings are present and consistent, and holds records that failEnforces the access controls configured in GothamClassifies data and corrects markings through trained classifiers
Data model mappingMaps source fields to the Gotham data model your organization has approvedProvides the platform's data modeling capabilitiesApproves the data model and changes to it
Access to dataMaps markings and source rules to the access controls you approveEnforces the access controls in GothamDecides who may see which data
Monitoring and incidentsWatches pipeline health and quality failures, and escalates incidentsHandles platform incidents under its termsLeads security incidents and data spills under your procedures
ChangesRaises, tests and applies pipeline changes through your change processReleases Gotham updates under its practicesApproves changes and change windows
User supportSupports data stewards and analysts on pipeline and data issuesSupports Gotham defects and features through its channelsFirst-line support for analysts

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

    The pipeline inventory

    Every source feeding Gotham in one list, with its last run, freshness and records held.

    SourceMethodLast runLoadedHeldStatus
    Source A: logistics reports (fictional)Database extractToday, 06:0018,24012Healthy
    Source B: field reports (fictional)Message feedToday, 07:153,105214Marking failures
    Source C: facilities register (fictional)File transferYesterday9600Healthy
    Source D: open-source feed (fictional)API2 days ago00Source not delivering
    Source E: equipment records (fictional)File transferToday, 05:307,41238Duplicates held
    Every source feeding Gotham in one list, with its last run, freshness and records held.
  2. Step 2

    A held batch

    Records that fail a check are held with the rule that stopped them, rather than loaded.

    Source B: field reports (fictional) · Run 4471

    Records received
    3,319
    Loaded
    3,105
    Held for markings
    201
    Held for quality
    13
    Assigned to
    Classifier queue and data steward queue

    Rules that failed

    • Field-level marking missing on the narrative field (201 records)
    • Report date in the future (9 records)
    • Unit identifier not found in reference list (4 records)
    Records that fail a check are held with the rule that stopped them, rather than loaded.
  3. Step 3

    A marking decision

    A trained classifier reviews the held records and records the decision; the suggested marking is only a suggestion.

    MR-0932 · 201 records from Source B (fictional)

    1. Records held: field-level marking missingPipeline check
    2. Suggested marking from the source's standing rules shown for reviewPipeline check
    3. Sample of records reviewed against the source's classification guidanceClassifier
    4. Decision recorded: apply marking to the batch, with reference to the guidanceClassifier
    5. Records re-run through checks and loadedMoraph data engineer
    6. Source owner asked to add the marking at originData steward
    A trained classifier reviews the held records and records the decision; the suggested marking is only a suggestion.
  4. Step 4

    Record lineage

    For any loaded record, lineage shows where it came from, which pipeline version loaded it and what was decided on the way.

    Record 88-31047 (fictional) · Lineage

    Source
    Source B: field reports (fictional)
    Extracted
    Run 4471
    Pipeline version
    v2.8
    Checks passed
    Quality 14 of 14, markings after decision
    Decisions
    Marking applied under MR-0932

    Transformations applied

    • Unit identifier matched to reference list
    • Date normalized to UTC
    • Mapped to the approved Report object type
    For any loaded record, lineage shows where it came from, which pipeline version loaded it and what was decided on the way.
  5. Step 5

    A pipeline change

    Changes to pipelines, rules and mappings are tested, approved through your process and recorded with their version.

    CR-0377 · Add duplicate rule for Source E (fictional)

    1. Change requested after repeated duplicatesData steward
    2. Rule written and tested against the last runMoraph data engineer
    3. Test result reviewed: 38 duplicates found, 0 false matches in sampleData steward
    4. Change approvedData owner
    5. Pipeline v1.6 deployed and first run confirmedMoraph data engineer
    Changes to pipelines, rules and mappings are tested, approved through your process and recorded with their version.
  6. Step 6

    The monthly service review

    Each month Moraph reviews the service with you: sources, runs, held records, decisions, changes and open actions.

    Monthly service review · Example Analysis Center (fictional)

    Sources live
    14
    Sources onboarding
    2
    Records held this month
    1,284
    Held records older than agreed
    37
    Changes applied
    6

    Actions agreed

    • Source owner B to add field-level markings at origin
    • Data owner to confirm whether Source D is still required
    • Moraph to clear aged held records with the steward queue
    Each month Moraph reviews the service with you: sources, runs, held records, decisions, changes and open actions.

Workflows

The principal workflows

  1. Onboard a source

    Each new source is authorized by your organization, profiled by Moraph, and mapped to the Gotham data model you have approved, with quality and marking rules agreed before any data is loaded.

    • Data owner requests the source and confirms the authority to use it
    • Moraph profiles a sample: fields, completeness, identifiers and markings
    • Field mapping to the approved data model drafted and reviewed
    • Quality and marking rules agreed with the data steward
    • Pipeline tested with sample data and approved for production
  2. Check and load

    On every run, records are validated, de-duplicated and checked for required markings before loading. Records that fail are held, not loaded, with the reason recorded.

    • Records received from the source on its schedule
    • Quality checks run for required fields, formats, duplicates and references
    • Marking checks confirm required classification and handling markings are present and consistent
    • Passing records loaded into Gotham with lineage recorded
    • Failing records held with the rule that stopped them
  3. Resolve held records

    Data stewards and trained classifiers work the held records: fixing them at the source, correcting markings under your procedures, or rejecting them, with each decision recorded.

    • Held records grouped by source and rule
    • Data steward reviews quality failures and decides fix, override or reject
    • Trained classifier reviews marking failures and records the decision
    • Corrected records re-run through the checks
    • Patterns of failure fed back to the source owner
  4. Trace and review

    For any record in Gotham, lineage shows its source, the pipeline version that loaded it, the checks it passed and any decisions made on it, for analysts and oversight staff.

    • Analyst or reviewer looks up a record's lineage
    • Source, extraction time and pipeline version shown
    • Checks passed and any steward or classifier decisions listed
    • Lineage exported for an oversight or analytic review
    • Questions about a source routed to its data owner

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.

Data owner

Mission data owner, collection or program manager, chief data officer's staff

Authorizes each source, confirms the authority to use it, and approves how it is mapped and governed.

Sees

  • Sources they own, with run health and held records
  • Mappings and rules for their sources
  • Changes affecting their sources

Does

  • Requests new sources and confirms the authority to use them
  • Approves mappings to the data model
  • Approves pipeline and rule changes for their sources
  • Decides whether a source is retired

Cannot

  • Change markings on records
  • Change access controls in Gotham through the service
  • Approve changes to sources they do not own
Approvals
Approves onboarding, mappings and changes for their sources; marking decisions remain with classifiers.
Notified about
Source run failures, sources not delivering, changes awaiting approval and aged held records.

Data steward

Data steward, data quality analyst, information manager

Keeps the data fit for analysis by approving quality rules and deciding on records held for quality.

Sees

  • Quality rules and their results
  • Records held for quality in their sources
  • Patterns of failure by source

Does

  • Approves quality rules
  • Decides to fix, override or reject held records, with a reason
  • Requests rule changes
  • Feeds recurring problems back to source owners

Cannot

  • Decide on marking failures
  • Deploy pipeline changes
  • Delete records from the audit trail
Approvals
Overrides of a quality rule are recorded with a reason and reported to the data owner.
Notified about
New held records in their queue and records approaching the age your procedures set.

Classifier

Derivative classifier, security manager, classification management officer

Decides on records held because of missing or inconsistent markings, under your classification procedures.

Sees

  • Records held for markings, with the rule that held them
  • Any suggested marking and its basis
  • The source's classification guidance reference

Does

  • Reviews held records and records a marking decision
  • Applies a decision to a batch where your procedures allow
  • Rejects records that should not be loaded
  • Reports suspected spillage under your procedures

Cannot

  • Change pipeline rules or mappings
  • Load records that have not passed checks
Approvals
Their decisions follow your classification procedures; batch decisions can require a second classifier if you choose.
Notified about
Records held for markings and possible spillage flagged by checks.

Analyst

Intelligence analyst, all-source analyst, operations analyst

Uses lineage to understand the records they work with and reports suspected data problems.

Sees

  • Lineage for records they are permitted to see
  • Source descriptions and freshness

Does

  • Looks up a record's lineage
  • Exports lineage for an analytic product
  • Reports suspected data issues to the data steward

Cannot

  • Change records, rules or markings
  • See held records
Approvals
None; their reports go to the data steward.
Notified about
Responses to data issues they reported.

Moraph data engineer

Moraph data engineer, Moraph service manager

Builds, runs and maintains the pipelines and checks, and runs the service, within the approvals your organization gives.

Sees

  • Pipeline code, configuration and run logs
  • Held records needed to diagnose pipeline issues, where cleared and permitted
  • Changes and service records

Does

  • Profiles sources and drafts mappings and rules
  • Builds and maintains pipelines under version control
  • Monitors runs and fixes pipeline failures
  • Applies approved changes
  • Runs monthly service reviews and manages vendor cases

Cannot

  • Make marking or classification decisions
  • Override a quality rule
  • Deploy a change without approval
Approvals
Every pipeline, rule and mapping change has a recorded approval from your organization.
Notified about
Run failures, sources not delivering, changes approved and vendor notices.

ISSM

Information system security manager, cybersecurity lead

Approves the security of the pipelines and the mapping of markings to access controls.

Sees

  • Pipeline architecture and environments
  • Marking-to-access mappings
  • Administrative activity and changes

Does

  • Approves pipeline architecture and environments
  • Approves changes to marking-to-access mappings
  • Reviews administrative activity
  • Uses evidence packages in your authorization

Cannot

  • Edit or delete audit records
  • Approve their own change requests
Approvals
Approves security-relevant changes; their own requests need a second designated approver.
Notified about
Security-relevant changes, possible spillage reports and incidents.

Oversight reviewer (read-only)

Intelligence oversight officer, inspector general staff, internal auditor

Reviews lineage, decisions and changes without being able to change anything.

Sees

  • Source authorizations and descriptions
  • Steward and classifier decisions
  • Lineage and change records within the scope granted

Does

  • Reads records within the scope granted
  • Exports evidence, with each export logged
  • Records review notes where enabled

Cannot

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

Permissions at a glance

ActionData ownerStewardClassifierAnalystMoraph engISSMOversight
Request and authorize a sourceOwn work onlyNo accessNo accessNo accessNo accessView onlyView only
Approve data model mappingApprovesView onlyNo accessNo accessNo accessNo accessNo access
Approve quality rulesApprovesFullNo accessNo accessNo accessNo accessNo access
Decide on quality holdsView onlyFullNo accessNo accessNo accessNo accessView only
Decide on marking holdsNo accessNo accessFullNo accessNo accessView onlyView only
Build and deploy pipeline changesApprovesNo accessNo accessNo accessFullNo accessNo access
Change marking-to-access mappingsNo accessNo accessNo accessNo accessFullApprovesNo access
View record lineageOwn work onlyFullFullOwn work onlyFullView onlyView only
Report a data issueFullFullFullFullFullNo accessNo access
View audit trailView onlyNo accessNo accessNo accessView onlyView onlyView only
Manage users and rolesNo accessNo accessNo accessNo accessFullApprovesNo access
  • Full
  • Own work only
  • Approves
  • View only
  • No access

How access is controlled

  • Duties are separated: data engineers build and run pipelines, data stewards decide on quality, trained classifiers decide on markings, and no one approves their own change.
  • Roles are scoped by source and by clearance, so people see only the sources and held records they are entitled to.
  • Suggested corrections are only suggestions. Every override, marking decision and rejection is made and recorded by a named person.
  • Moraph's accounts are named and role-based, and tickets for defense and intelligence clients are handled only by US citizens with active clearances.

Features

What it does

Managed pipelines

Moraph builds, runs and maintains the pipelines from each authorized source into Gotham, under version control.

Source profiling

Each new source is profiled for fields, completeness, identifiers and markings before mapping begins.

Data model mapping

Source fields are mapped to the Gotham data model your organization has approved, with the mapping documented.

Quality checks

Required fields, formats, duplicates and references checked on every run, with rules your data stewards approve.

Marking checks

Records are checked for required classification and handling markings and for consistency between record-level and field-level markings.

Hold, don't load

Records that fail a check are held with the reason rather than loaded, so problems are fixed before analysts see them.

Steward and classifier queues

Held records go to the right people: quality failures to data stewards, marking failures to trained classifiers.

End-to-end lineage

Every loaded record carries its source, extraction time, pipeline version, checks passed and decisions made on it.

Access mapping

Markings and source rules are mapped to the access controls you approve in Gotham, and the mapping is reviewed with your security staff.

Pipeline monitoring

Moraph watches runs, volumes and failures, and raises issues before stale or incomplete data reaches analysts.

Change control

Pipeline, rule and mapping changes are raised, tested, approved through your process and recorded.

Suggested fixes, human decisions

Where a rule suggests a likely correction, such as a missing marking inferred from the source, a person reviews and decides; nothing is changed automatically.

Integrations

How it connects to your systems

Connects toHowWhat flows
Palantir GothamChecked records are loaded through the integration interfaces Palantir provides for your deployment, mapped to your approved data model.Out: validated records with markings and lineage references.
Source systemsAuthorized sources are connected by file transfer, database extract, message feed or API, as each source allows.In: source records on each source's schedule.
Cross-domain transferWhere a source sits on a different network, data arrives through the cross-domain solution your organization has approved, including Moraph's Cross-Domain Solution (CDS) Transfer Agent.In: transferred records with their transfer references.
Identity providerMoraph's governance tools are reached through your identity provider, with groups mapped to roles.In: user identity and group membership.
SIEMPipeline runs, held records, decisions and administrative actions are sent to your SIEM.Out: pipeline and governance events.
IT service managementChanges, incidents and source requests are tracked in your service management tool, or in Moraph's if you have none.In and out: tickets, approvals and status.
Data catalogSource descriptions, mappings and lineage can be published to the data catalog your organization uses.Out: source metadata, mappings and lineage.

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

Staff sign in through your identity provider, so your authentication policies apply.

Role-based access

Data engineers, stewards and classifiers see only the sources and held records their role and clearance allow.

Encryption and keys

Data in pipelines and holding areas is encrypted, with keys Moraph staff cannot use without explicit, time-bound authorization.

Complete audit trail

Every run, check result, decision and change is logged with the person and time.

Cleared US support staff

Tickets for federal and defense clients are handled only by US citizens with active clearances.

Your authority on classified networks

Pipelines on classified networks are built and run under your organization's authority and procedures; Moraph holds no accreditation of its own.

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.

Pipeline operations

Run health and freshness

For data owners and Moraph service manager

Each source's last run, records received, loaded and held, and whether data is as fresh as agreed.

Break down by
Source, Run, Status, Period
Delivered as
Live view; monthly service review pack; CSV export
Used for
Spotting sources that have stopped or slowed before analysts are affected.

Held records by age

For data stewards, classifiers, data owners

Records waiting for a decision, by rule, queue and age.

Break down by
Source, Rule, Queue, Age band
Delivered as
Live view; scheduled email
Used for
Making sure held records are decided rather than left to accumulate.

Source onboarding

For data owners and program office

Sources requested, in profiling, mapping, testing and live.

Break down by
Source, Stage, Data owner
Delivered as
Live view; monthly service review pack
Used for
Tracking new sources through to production.

Data quality

Quality failures by rule

For data stewards and source owners

Quality failures by source and rule over time, with how they were decided.

Break down by
Source, Rule, Decision, Period
Delivered as
Live view; CSV export
Used for
Showing source owners where to fix problems at origin.

Overrides

For data owners and oversight reviewers

Every quality rule override with the steward, reason and records affected.

Break down by
Source, Rule, Steward, Period
Delivered as
Live view; PDF and CSV export
Used for
Checking that overrides are rare and justified.

Markings and access

Marking failures and decisions

For classification management staff and ISSM

Records held for markings, by source and failure type, with the decisions made.

Break down by
Source, Failure type, Decision, Classifier
Delivered as
Live view; PDF export
Used for
Finding sources with systemic marking problems and evidencing decisions.

Marking-to-access mapping

For iSSM and data owners

How each marking and source rule maps to access controls in Gotham, with change history.

Break down by
Marking, Access control, Change date
Delivered as
Live view; PDF export
Used for
Reviewing that access in Gotham follows the markings as approved.

Oversight and audit

Lineage extract

For analysts and oversight reviewers

For selected records, source, extraction, pipeline version, checks and decisions.

Break down by
Record, Source, Pipeline version
Delivered as
On request; CSV and PDF export
Used for
Supporting analytic products and oversight reviews with the origin of the data.

Change history

For iSSM, data owners, oversight reviewers

Every pipeline, rule and mapping change with its request, test, approval and deployment.

Break down by
Source, Change type, Approver, Period
Delivered as
Live view; PDF and CSV export
Used for
Showing that each change was tested, approved and recorded.

Source authorization register

For oversight reviewers and data owners

Each source with its owner, the authority recorded for its use, and when it was last reviewed.

Break down by
Source, Data owner, Review date
Delivered as
Live view; PDF export
Used for
Confirming every source feeding Gotham is authorized and reviewed.

Monthly service review pack

For program office, data owners, Moraph service manager

Sources, runs, held records, decisions, changes, vendor cases and open actions for the month.

Break down by
Period, Source
Delivered as
PDF; scheduled email
Used for
Running the monthly service review and recording the actions agreed.

Exports, access and evidence

  • Reports can be exported to CSV and evidence reports to PDF, and scheduled to arrive by email for the people entitled to see them.
  • Reports respect each viewer's role and clearance: a data owner sees their own sources, a classifier sees marking queues, and oversight reviewers get read-only access within a set scope.
  • Pipeline and governance events are sent to your SIEM, so your own security tooling holds the primary record under your retention policy.
  • Lineage and decisions are kept for the retention period your organization sets, including for records later removed from Gotham.
  • Evidence reports can be run as of a past date and give the same result each time. Running and exporting a report is itself recorded.

Deployment

Where and how it runs

Alongside your Gotham deployment

Pipelines and governance tools run in the same environment as your Gotham deployment, on infrastructure your organization authorizes.

US-hosted service tooling

Where unclassified service tooling is used, it is hosted in Moraph's United States region only.

Classified networks

Where pipelines run on classified networks, Moraph's cleared staff work under your organization's authority and procedures, 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.

Discovery

We inventory the sources feeding Gotham today, how they are loaded, and the data model and access controls in use. We need your data owners and the team that administers Gotham.

Governance rules

Quality and marking rules are agreed with your data stewards and classification management staff, and documented.

Pipeline build

Pipelines are rebuilt or built new under version control, with checks, holding areas and lineage recording, starting with the sources you choose.

Parallel run

Where existing loads are being replaced, old and new pipelines run side by side and differences are reviewed before cutover.

Queues and roles

Steward and classifier queues, roles and escalation paths are configured to match your procedures.

Transition to operations

Runbooks, monitoring, reporting and service reviews are agreed, and the service moves into steady-state management.

Limitations

What it does not do

Worth knowing before you evaluate it.

  • Moraph is not Palantir. Palantir owns and supports Gotham, and its own service commitments, roadmap and outages apply.
  • Licenses for Gotham are subject to Palantir's terms.
  • Moraph does not classify information. Marking checks find missing or inconsistent markings; classification decisions are made by your trained classifiers.
  • Checks catch the problems their rules describe. They cannot make a source accurate, and data that is wrong but well formed can still pass.
  • Moraph does not decide who may see data. Access controls in Gotham are configured as your organization approves.
  • The service does not change Gotham itself or its analytic features; it governs the data that goes into it.
  • Authority to collect, retain and use each source, including any information about US persons, is your organization's responsibility and is confirmed before a source is onboarded.
  • Moraph does not hold accreditation for classified environments; operations there take place under your organization's authority.

Evaluation checklist

What to test in a demonstration or pilot

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

  1. Pick two sources that cause the most analyst complaints and have them profiled
  2. Review the proposed quality and marking rules with your data stewards and classification management staff
  3. Trace a sample record from source to Gotham and check the lineage is complete
  4. Walk a held record through the steward and classifier queues
  5. Confirm how markings map to access controls in your Gotham deployment
  6. Read the responsibilities table against your Palantir support arrangements

Questions

Frequently asked questions

Do we need to buy Gotham from Moraph?

No. Moraph can work with the Gotham licenses you already hold, or coordinate licensing under Palantir's terms where that is agreed.

Does Moraph classify our data?

No. The service finds missing or inconsistent markings and holds those records. Your trained classifiers decide on them under your procedures.

Will this change what analysts see in Gotham?

Analysts work in Gotham as before. The difference is in the data behind it: records are checked before they load, and each one carries its lineage.

Is the service accredited for classified networks?

Moraph holds no accreditation of its own. Work on classified networks takes place under your organization's authority, with Moraph supplying control mappings and evidence for your authorization.

How is it priced?

A managed service fee based on the sources and pipelines in scope and the environments they run in, with implementation charged separately and any Gotham licensing at Palantir's terms. See Working with Moraph for what drives a quotation.

Who owns the pipelines?

Your organization does. Pipeline code, rules, mappings and documentation are yours, and the handover at the end of the agreement is set out in the contract.

Next steps

Evaluate Palantir "Gotham" Integration & Governance

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