From 5ff3241e6cc89a5a8f3b89722dc6641ce5b0241a Mon Sep 17 00:00:00 2001 From: John X Date: Fri, 5 Jun 2026 17:20:23 +0100 Subject: [PATCH 1/2] docs: reconcile "signed result" and "Policy Attestation" terminology The concept pages call the output of Verify and Compute a "signed result," while the schemas reference, the SDK, and the API call the same artifact a "Policy Attestation." Nothing stated that these are the same thing, so a reader (or an AI agent ingesting the docs) could reasonably treat them as two distinct objects. Add a short note on the Signed Results page pinning the two terms to one artifact: "signed result" is the concept, "Policy Attestation" is its concrete EAS-encoded form. --- concepts/signed-results.mdx | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/concepts/signed-results.mdx b/concepts/signed-results.mdx index 56619fa..d274bb0 100644 --- a/concepts/signed-results.mdx +++ b/concepts/signed-results.mdx @@ -9,6 +9,10 @@ description: "Output formats from verification and computation — and how to us Both the [Verify](/concepts/verify) and [Compute](/concepts/compute) endpoints return signed results — cryptographically signed records of what was computed, what inputs were used, and what the answer was. The signature comes from the Astral signing key, held inside the [TEE](/concepts/astral-location-services). + + **"Signed result" and "Policy Attestation" are the same artifact.** "Signed result" is the conceptual name used throughout these docs; **Policy Attestation** is its concrete encoded form — the [EAS schema](/resources/schemas#policy-attestation-schemas) the result is serialized into (`BooleanPolicyAttestation` for predicates, `NumericPolicyAttestation` for measurements). A signed result submitted to EAS *is* a Policy Attestation. The SDK, the schemas reference, and the API use "Policy Attestation" for the on-chain object; the concept pages say "signed result" for the same thing. + + ## What a Signed Result Proves Under attestation (see deployment status below), a signed result is intended to prove three things: From 638eb6e836d755fcb3b04ca0802a63457b14d79e Mon Sep 17 00:00:00 2001 From: John X Date: Fri, 5 Jun 2026 17:20:33 +0100 Subject: [PATCH 2/2] docs: name the zone registry and frame compute as policy evaluation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The docs accurately describe the mechanics — predicate operations in a TEE, EAS UIDs as compute inputs, resolvers triggering on-chain logic — but never connect them into the capability they add up to. As a result the system reads as a geocomputation oracle, and the policy-evaluation layer (a core differentiator) is invisible to a reader skimming the conceptual spine. Add a "Zones and policy evaluation" section to the Compute concept page that names three things already true of the system but never stated together: - a predicate result is a policy decision (the boolean is the verdict) - passing a boundary by EAS UID gives a reusable, verifiable zone registry with no bespoke registry service — provenance and integrity come from the attestation, and every evaluation references the same geometry by UID - the signed verdict drives an on-chain resolver; the rule is evaluated offchain in the TEE, only the verdict and its action touch the chain Surface the same framing in one line on the how-it-works pipeline, linking to the new section, so the capability is visible on the most-read page. --- concepts/compute.mdx | 14 ++++++++++++++ how-it-works.mdx | 2 ++ 2 files changed, 16 insertions(+) diff --git a/concepts/compute.mdx b/concepts/compute.mdx index aa3cacd..1d9bfd1 100644 --- a/concepts/compute.mdx +++ b/concepts/compute.mdx @@ -69,6 +69,20 @@ Every compute operation returns a [signed result](/concepts/signed-results) cont The signed result can be used offchain (in an agent, application, or database) or submitted onchain via EAS delegated attestation. EAS resolvers allow those attestations to trigger smart contract logic. +## Zones and policy evaluation + +A predicate operation — `contains`, `within`, `intersects` — is a policy decision. "Is this verified position inside the permitted zone?" is at once a spatial question and a rule, and the boolean answer is the verdict. Astral evaluates the rule inside the TEE and signs the verdict; the application — or a resolver contract — decides what the verdict triggers. + +### Zones as reusable, verifiable references + +The boundary in a policy check doesn't have to travel with every request. Because any input can be a [signed location record](#accepted-inputs) — an EAS attestation UID — you can register a zone once as a [Location attestation](/resources/schemas#location-attestation-schema) and reference it by UID thereafter. Astral fetches the stored geometry into the TEE at evaluation time. + +That gives you a reusable registry of zones — permitted corridors, jurisdictional boundaries, geofences — without a bespoke registry service. The boundary's provenance and integrity come from its attestation, and every evaluation references the exact same geometry by UID, so a policy decision is reproducible and auditable: anyone can confirm *which* zone was checked. + +### From verdict to action + +Submitted onchain, a [Policy Attestation](/concepts/signed-results) carrying a `true`/`false` verdict can drive an [EAS resolver](/concepts/signed-results#using-signed-results-onchain) — releasing escrow, granting access, gating a mint to inside a boundary. The spatial rule is evaluated offchain in the TEE; only the signed verdict and the on-chain action it triggers touch the chain. + ## What's Next The current operation set covers the most common spatial questions, but PostGIS exposes a much larger surface. Areas we're exploring: diff --git a/how-it-works.mdx b/how-it-works.mdx index 36ac012..84c72e8 100644 --- a/how-it-works.mdx +++ b/how-it-works.mdx @@ -49,6 +49,8 @@ The output is a **credibility vector**: structured scores quantifying how well t 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). + **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."