docs: surface the policy-evaluation layer and reconcile attestation terminology#35
Open
johnx25bd wants to merge 2 commits into
Open
docs: surface the policy-evaluation layer and reconcile attestation terminology#35johnx25bd wants to merge 2 commits into
johnx25bd wants to merge 2 commits into
Conversation
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.
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.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The docs are accurate about what's built and honestly scoped, but two things make them read as a geocomputation oracle rather than what Astral actually is — verifiable location proofs plus a policy-evaluation engine with an EAS-based zone registry that triggers on-chain action. Both surfaced while watching an AI agent build a wrong mental model from
llms-full.txt:These are framing/consistency gaps, not factual corrections — nothing here overclaims maturity, and every statement is already true of the system.
Changes
concepts/signed-results.mdx— short note pinning "signed result" (the concept) and "Policy Attestation" (its concrete EAS-encoded form) to one artifact.concepts/compute.mdx— new "Zones and policy evaluation" section: predicate result = policy verdict; EAS UID = reusable, verifiable zone registry with no bespoke service; signed verdict → on-chain resolver, with the rule evaluated offchain in the TEE.how-it-works.mdx— one line in the pipeline surfacing the policy-evaluation framing on the most-read page, linking to the new section.Two atomic commits (terminology; framing). All internal anchors verified against existing headings. Prose-only, matches existing voice and MDX components.
Note on scope
This is the bounded subset of a larger docs-accuracy idea — the highest-leverage pieces that close the specific gaps that mislead a skimming reader (human or agent). Larger follow-ups (a per-component build-status table, an adversarial "summarize the docs and check against ground truth" QA step) are deliberately left out.