> ## Documentation Index
> Fetch the complete documentation index at: https://astral-6ef288be-docs-policy-evaluation-framing.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# How It Works

> The full pipeline from location evidence to signed results

<Note>**Research Preview** — APIs may change. [GitHub](https://github.com/AstralProtocol)</Note>

# How it works

Location data is easy to fake and hard to verify. GPS can be spoofed with a \$20 app. IP geolocation is trivially manipulated. Self-reported coordinates carry no proof of origin. When a delivery platform confirms a drop-off, a compliance system checks a geofence, or an autonomous agent makes a spatial decision — the location data underneath is taken on faith.

Astral exists to change that. The system provides a pipeline that collects location evidence, bundles it into verifiable artifacts, evaluates its credibility, runs spatial computations on it, and delivers signed results that any downstream system can independently verify.

## The Pipeline

### 1. Collect location evidence

Devices collect signals from **proof-of-location systems** — independent systems that produce evidence about where something is. A phone's secure enclave can attest to sensor readings. A network of infrastructure nodes can triangulate position via latency measurements. Each system has different strengths, weaknesses, and trust properties.

Each [location proof plugin](/plugins/overview) connects to a proof-of-location system, collects signals, and processes them to produce a [location stamp](/concepts/location-stamps) — an individual piece of evidence about the location of a device, person, asset or event.

<Tip>
  **Why this step matters:** Self-reported location is trivially spoofable. Composing evidence from independent proof-of-location systems raises the cost of forgery — which is the real goal, since absolute certainty about physical location is not achievable.
</Tip>

### 2. Create a location proof

A **location stamp** is a piece of signed, structured evidence from a single proof-of-location system about an observed location. Each location stamp carries enough information to verify its internal validity: signatures, temporal footprint, and plugin identification.

One or more location stamps bundle with a **location claim** — an assertion about where and when an event occurred — to form a **location proof**. The location proof is the verifiable artifact: a claim paired with its supporting evidence.

`proof = {claim, [stamps...]}`

<Tip>
  **Why this step matters:** Attaching structured, composable evidence to claims give people and systems receiving location proofs what they need to verify and assess credibility. A location proof separates the assertion ("I was here") from the evidence ("here's why you should believe me"), which makes both independently evaluable.
</Tip>

### 3. Verify the location proof

Submit the location proof to Astral's Verify endpoint. Inside a Trusted Execution Environment (TEE), the system evaluates the location stamp — checking signatures, structure, and signal consistency — then assesses how well the evidence supports the location claim. For multi-stamp location proofs, it also cross-correlates across independent sources.

The output is a **credibility vector**: structured scores quantifying how well the evidence supports the claim across multiple dimensions (spatial, temporal, validity, independence, and more — this is an active research area). Location proof verification does not output a binary yes/no — application developers decide what dimensions they value and the threshold they need to meet.

<Tip>
  **Why this step matters:** Independent, structured evaluation of location evidence. The credibility vector gives applications enough information to make risk-appropriate decisions — a \$10 check-in reward can accept lower confidence than a \$10M physical asset verification.
</Tip>

### 4. Compute spatial relationships

Run geospatial operations — distance, containment, intersection, area, length — on location data inside the Astral TEE. The compute endpoints accept raw GeoJSON, signed location records, or verified location proofs as inputs. [PostGIS](https://postgis.net/) (backed by the [GEOS](https://libgeos.org/) library, the same computational geometry engine used by QGIS and other open-source geospatial tools) performs the computation; the TEE signs the result.

A predicate operation is also a **policy decision**: "is this verified position inside the permitted zone?" is a rule, and the signed boolean is the verdict. Zones can be passed inline or referenced by EAS UID — a reusable, verifiable registry of boundaries — and the verdict can drive an on-chain resolver. See [zones and policy evaluation](/concepts/compute#zones-and-policy-evaluation).

<Tip>
  **Why this step matters:** Verifiable spatial answers. The signed result proves not just "what was the answer" but "the answer was computed correctly by trusted code on these specific inputs."
</Tip>

### 5. Use the signed result

The signed result goes wherever it needs to — an autonomous agent's decision loop, a backend database, a compliance report, or a smart contract via an EAS attestation. It carries its own proof of correctness, so any downstream consumer can verify it independently without re-executing the computation or trusting the intermediary.

<Tip>
  **Why this step matters:** Portable, independently verifiable spatial facts. The result is useful whether it stays offchain or goes onchain.
</Tip>

## Architecture

```mermaid theme={null}
graph LR
    subgraph Client["🔵 Client"]
        D[Device / Sensor] --> P1[Plugin A]
        D --> P2[Plugin B]
        P1 --> S1[Stamp]
        P2 --> S2[Stamp]
        S1 --> LP[Location Proof]
        S2 --> LP
        CL[Claim] --> LP
    end

    subgraph TEE["🟡 Astral TEE"]
        LP --> VE[Verify]
        VE --> CV[Credibility Vector]
        LD[Location Data] --> CO[Compute]
        CV -.-> CO
        CO --> SR[Signed Result]
    end

    SR --> AG[Agent]
    SR --> AP[Application]
    SR --> SC[Smart Contract]

    style Client fill:#e8f4fd,stroke:#4a90d9,color:#000
    style TEE fill:#fef9e7,stroke:#d4a63a,color:#000
```

<AccordionGroup>
  <Accordion title="Location proof creation + verification" icon="shield-check">
    Evidence collection → composition → verification. Produces a credibility vector that tells you how much to trust the location claim. The verified location proof can then flow into the Compute service, or be used on its own.
  </Accordion>

  <Accordion title="Geocomputation" icon="calculator">
    Location data (raw, signed, or verified) → spatial operation → signed result. Produces a cryptographically signed spatial answer. The dashed arrow from the credibility vector to Compute indicates that verified proofs *can* feed into computation, but don't have to.
  </Accordion>
</AccordionGroup>

<Info>
  The two capabilities compose but don't require each other. A verified location proof is valuable on its own — it doesn't need to flow into the Compute service. And a compute operation can run on any location data, not just verified location proofs.
</Info>

## What's verified vs. what's trusted

The TEE guarantees that computation executes correctly — the code that ran is the code that was attested, inputs weren't tampered with, and the signing key never leaves the enclave. That's the "verifiable" part.

<Warning>
  The truthfulness of location inputs is a separate question. It depends on the strength of the location proof: how many independent proof-of-location systems contributed evidence, how resistant those systems are to forgery, and whether the evidence is consistent. Astral evaluates this and reports it honestly via the credibility vector — but it cannot make weak evidence strong.
</Warning>

For a detailed accounting of what exactly is verified and what trust assumptions remain, see the [Trust Model](/trust-model/architecture).

<Card title="Next: Location data" icon="map" href="/concepts/location-data">
  How Astral represents and verifies spatial data
</Card>