diff --git a/docs/core-concepts/location-proofs.md b/docs/core-concepts/location-proofs.md
index 5be6d4e..a138257 100644
--- a/docs/core-concepts/location-proofs.md
+++ b/docs/core-concepts/location-proofs.md
@@ -1,30 +1,40 @@
 # Location Proofs
 
-Location proofs are verification evidence that can be attached to location attestations. While location attestations contain the actual spatial data (coordinates, geometries, etc.), location proofs provide evidence or verification of the authenticity of that spatial data.
+Location proofs are digital artifacts that combine multiple independent pieces of evidence to support claims about *where and when* events occur. They serve as the verification layer for location attestations in the Astral ecosystem.
 
-## What are Location Proofs?
+## Core Concepts
+
+A **location stamp** is a single piece of verifiable evidence (e.g., a GNSS reading, an IP lookup, or a signed affidavit).
+A **location proof** is what you get when multiple stamps are combined and verified together to create a higher-confidence claim.
 
 Location proofs serve as the verification layer for location attestations. They:
 
-- Provide evidence that a claim about a location is valid
+- Combine multiple independent evidence sources to increase confidence
 - Can be generated through various verification strategies
 - Are attached to location attestations as part of the Location Protocol
+- Make location fraud more difficult through multifactor verification
 
-## Types of Location Proofs
+## Evidence Strategies
 
-The Location Protocol supports many different approaches to verification:
+The Location Protocol supports seven broad categories of location evidence:
 
-- **Authority-based proofs**: Verification from trusted entities like event organizers
-- **Social proofs**: Verification from other users who can confirm location claims
-- **Hardware-based proofs**: Evidence from devices like Bluetooth beacons, NFC, or RFID
-- **Network-based proofs**: Evidence from network triangulation or signal analysis
-- **Sensor data proofs**: Evidence from environmental readings that match expected values
+- **[Machine Identifiers](../location-proofs/strategies/machine-identifiers.md)**: Wi-Fi, Bluetooth, cell towers, IP addresses
+- **[Network Measurements](../location-proofs/strategies/network-measurements.md)**: GNSS, RTT latency, signal strength
+- **[Sensor Data](../location-proofs/strategies/sensor-data.md)**: IMU, camera, microphone, environmental sensors
+- **[Delegated](../location-proofs/strategies/delegated.md)**: Third-party services like ride logs, utility bills
+- **[Social](../location-proofs/strategies/social.md)**: Peer attestations and community validation
+- **[Authority](../location-proofs/strategies/authority.md)**: Institutional records and certifications
+- **[Legal](../location-proofs/strategies/legal.md)**: Formal documents like bills of lading
 
 ## Relationship to Location Attestations
 
 Location attestations are the primary data structure in the Location Protocol, while location proofs provide the evidence that makes these attestations trustworthy:
 
 - **Location attestation**: "I was at coordinates 37.7749° N, 122.4194° W at 2:00pm"
-- **Location proof**: Evidence supporting that claim, such as a beacon signal, network data, or third-party verification
+- **Location proof**: Multiple pieces of evidence supporting that claim, such as GNSS data + Wi-Fi signals + device attestation
+
+## Research & Implementation
+
+For detailed technical research on location proof strategies, signals, and implementation approaches, see the [Location Proofs](../location-proofs/overview.md) section.
 
-The Location Protocol is designed to accommodate various proof strategies through the [Location Proof Extensions](../location-protocol/strategies-recipes.md) framework.
\ No newline at end of file
+The Location Protocol accommodates various proof strategies through the [Location Proof Extensions](../location-protocol/strategies-recipes.md) framework.
\ No newline at end of file
diff --git a/docs/location-proofs/content.md b/docs/location-proofs/content.md
new file mode 100644
index 0000000..dd3fc7c
--- /dev/null
+++ b/docs/location-proofs/content.md
@@ -0,0 +1,387 @@
+This contains
+	1.	The directory tree 
+	2.	Copy-pasteable Markdown stubs for each page.
+	3.	Internal links consistent with the structure.
+
+⸻
+
+Directory structure
+
+/docs/
+└─ location-proofs/
+   ├─ overview.md
+   ├─ strategies/
+   │  ├─ index.md
+   │  ├─ machine-identifiers.md
+   │  ├─ network-measurements.md
+   │  ├─ sensor-data.md
+   │  ├─ delegated.md
+   │  ├─ social.md
+   │  ├─ authority.md
+   │  └─ legal.md
+   ├─ signals/
+   │  └─ index.md
+   ├─ integrity/
+   │  └─ index.md
+   ├─ device-os/
+   │  └─ index.md
+   ├─ plugins/
+   │  └─ index.md
+   ├─ recipes/
+   │  └─ index.md
+   ├─ glossary.md
+   └─ templates/
+      ├─ strategy.md
+      ├─ signal.md
+      ├─ integrity.md
+      ├─ plugin.md
+      └─ recipe.md
+
+
+⸻
+
+Page stubs
+
+overview.md
+
+# Location Proofs (Research)
+
+This section of the docs is a living research reference for **location proofs**:  
+digital artifacts that combine multiple independent pieces of evidence to support claims about *where and when* events occur.
+
+A **location stamp** is a single piece of verifiable evidence (e.g., a GNSS reading, an IP lookup, or a signed affidavit).  
+A **location proof** is what you get when stamps are combined and verified together.
+
+The subsections here document:
+- [Strategies](./strategies/index.md): broad categories of how location can be derived.
+- [Signals](./signals/index.md): raw observables used as evidence.
+- [Integrity](./integrity/index.md): mechanisms that raise confidence in signals.
+- [Device / OS](./device-os/index.md): the platforms where signals and proofs can be generated.
+- [Plugins](./plugins/index.md): implementations that package signals into stamps.
+- [Recipes](./recipes/index.md): combinations of plugins into multifactor proofs.
+- [Glossary](./glossary.md): quick definitions and cross-links.
+
+This section is meant to be extensible. Over time, individual signals, plugins, and recipes will grow into their own pages.  
+For now, the focus is on creating a clear reference scaffold and a research agenda.
+
+
+⸻
+
+strategies/index.md
+
+# Location Strategies
+
+**Strategies** are broad categories of how location can be derived.  
+They provide the conceptual map under which specific [signals](../signals/index.md) are organized.
+
+The seven strategies we track:
+
+- [Machine Identifiers](./machine-identifiers.md)
+- [Network Measurements](./network-measurements.md)
+- [Sensor Data](./sensor-data.md)
+- [Delegated](./delegated.md)
+- [Social](./social.md)
+- [Authority](./authority.md)
+- [Legal](./legal.md)
+
+Each strategy page gives a concise definition and typical examples.
+
+⸻
+
+strategies/machine-identifiers.md
+
+# Machine Identifiers
+
+**Definition:**  
+Location derived by detecting machine identifiers and comparing them with a georeferenced lookup table.
+
+**Examples:**  
+- Wi-Fi SSIDs and BSSIDs  
+- Bluetooth MAC addresses  
+- Cell tower IDs  
+- IP addresses / ASNs  
+- DePIN beacons (e.g., Helium)
+
+**Derivation method:**  
+Observed identifiers → cross-reference against a known dataset → location estimate.
+
+**Risks:**  
+Identifiers can be cloned or replayed. Databases may be stale or incomplete.
+
+
+⸻
+
+strategies/network-measurements.md
+
+# Network Measurements
+
+**Definition:**  
+Location derived from measured values produced by network interactions.
+
+**Examples:**  
+- GNSS pseudoranges (satellite timing)  
+- RTT / latency between nodes  
+- WitnessChain co-location checks  
+- Proximum timing proofs  
+- RSSI trilateration (signal strength)
+
+**Derivation method:**  
+Measured values → compute position using physics or geometry.
+
+**Risks:**  
+Measurements can be manipulated (signal jamming, GNSS spoofing, latency injection).
+
+
+⸻
+
+strategies/sensor-data.md
+
+# Sensor Data
+
+**Definition:**  
+Location context inferred from raw sensor readings produced by a device.
+
+**Examples:**  
+- Inertial sensors (IMU: accelerometer, gyroscope)  
+- Microphone acoustics  
+- Camera EXIF or image content  
+- LiDAR or depth sensors
+
+**Derivation method:**  
+Raw sensor traces → pattern matching or model analysis → location context.
+
+**Risks:**  
+Sensors can be noisy, biased, or deliberately spoofed (e.g., replayed images, synthetic audio).
+
+
+⸻
+
+strategies/delegated.md
+
+# Delegated
+
+**Definition:**  
+Location evidence derived from data held by a trusted third-party service.
+
+**Examples:**  
+- Uber ride logs  
+- Mobile carrier call detail records (CDRs)  
+- Utility bills  
+- Bank transaction metadata
+
+**Derivation method:**  
+Delegated service provides a record → verifier checks consistency and origin.
+
+**Risks:**  
+Centralized trust dependency. Privacy and data access constraints.
+
+
+⸻
+
+strategies/social.md
+
+# Social
+
+**Definition:**  
+Location evidence generated through attestations by peers or communities.
+
+**Examples:**  
+- Witness signatures (friends confirming co-presence)  
+- Crowdsourced validation of events or assets  
+- Community mapping projects
+
+**Derivation method:**  
+Multiple independent social attestations → combined into a verifiable record.
+
+**Risks:**  
+Sybil attacks (fake identities), collusion, and subjective bias.
+
+
+⸻
+
+strategies/authority.md
+
+# Authority
+
+**Definition:**  
+Location evidence provided by an institution or organization with formal credibility.
+
+**Examples:**  
+- Government cadastral databases  
+- Academic field research logs  
+- NGO or standards body certifications
+
+**Derivation method:**  
+Authoritative institution issues signed record → verifier trusts based on institutional credibility.
+
+**Risks:**  
+Centralized trust, political bias, or institutional capture.
+
+
+⸻
+
+strategies/legal.md
+
+# Legal
+
+**Definition:**  
+Location evidence embedded in formal legal documents.
+
+**Examples:**  
+- Bills of lading  
+- Customs or shipping documents  
+- Affidavits  
+- Land deeds
+
+**Derivation method:**  
+Legal document includes place and time → verifier checks authenticity and legal standing.
+
+**Risks:**  
+Forgery, jurisdictional variance, enforcement limitations.
+
+
+---
+
+# Machine Identifiers
+
+**Definition:** Location derived by detecting and comparing machine identifiers against a georeferenced lookup table.
+
+**Examples:**
+- Wi-Fi SSIDs and BSSIDs
+- Bluetooth MAC addresses
+- Cell tower IDs
+- IP addresses
+- DePIN beacons (e.g., Helium)
+
+**Notes:**  
+These identifiers are reported values. They must be compared with a reference dataset (crowdsourced, carrier-provided, or open) to yield a location estimate.
+
+(repeat similar style for other 6 strategy pages, each concise, based on our framing)
+
+⸻
+
+signals/index.md
+
+# Location Signals (Research Agenda)
+
+This section will contain **raw signals**, categorized under the [strategies](../strategies/index.md).  
+Signals are the **observables** that plugins can transform into verifiable stamps.
+
+For now, we treat this as a **research agenda**: a living list of signals we intend to document.
+
+| Signal | Strategy | Context |
+|--------|----------|---------|
+| GNSS pseudoranges | Network Measurements | Core satellite navigation raw values |
+| Wi-Fi SSID/BSSID | Machine Identifiers | Device-visible broadcast IDs |
+| Bluetooth MACs | Machine Identifiers | Short-range device identifiers |
+| Cell IDs | Machine Identifiers | Tower IDs used by carriers |
+| IP / ASN | Machine Identifiers | Reported by network layer |
+| RTT latency | Network Measurements | Round-trip time between nodes |
+| RSSI trilateration | Network Measurements | Signal strength analysis for range |
+| Inertial IMU | Sensor Data | Accelerometer/gyroscope traces |
+| Microphone acoustics | Sensor Data | Ambient sound signatures |
+| Camera EXIF | Sensor Data | Embedded photo metadata |
+| Delegated datasets | Delegated | Uber ride, bank statement, utility bill |
+| Legal documents | Legal | Bills of lading, customs docs, affidavits |
+
+Each entry will eventually have its own page. For now, this list signals where research is headed.
+
+
+⸻
+
+integrity/index.md
+
+# Integrity Assurances (Research Agenda)
+
+Integrity assurances are **mechanisms that increase trust** in a signal or plugin.  
+They are not signals themselves but modifiers of credibility.
+
+Examples under study:
+- **Android Play Integrity API** — attests to app and device state.
+- **Apple App Attest** — verifies iOS app legitimacy.
+- **Trusted Execution Environments (TEE)** — enclaves like TrustZone, SGX, Secure Enclave.
+- **Hardware-backed keys** — signing with embedded secure elements.
+- **Secure boot chains** — device starts in a verified state.
+- **C2PA content credentials** — media provenance.
+- **Timestamp notaries** — external time anchors.
+
+Future pages will expand these into detailed references.
+
+
+⸻
+
+device-os/index.md
+
+# Device / OS
+
+Devices and operating systems determine which [signals](../signals/index.md) are accessible, and what [integrity assurances](../integrity/index.md) are available.
+
+**High-level notes:**
+- **Android**: Broadest access to raw signals (GNSS, Wi-Fi, Bluetooth, IMU). Supports Play Integrity API.  
+- **iOS**: More restricted APIs, but includes App Attest and Secure Enclave for integrity.  
+- **IoT / Linux boards**: Flexible access, but security posture depends heavily on hardware and software configuration.  
+
+This area is where implementation gets closest to real-world feasibility. We are tracking it, but holding more detailed research internally for now.
+
+
+⸻
+
+plugins/index.md
+
+# Location Stamp Plugins
+
+**Plugins** are implementations that transform raw [signals](../signals/index.md) into verifiable **location stamps**.  
+Each plugin references the signals it uses, the [devices/OS](../device-os/index.md) it runs on, and any [integrity assurances](../integrity/index.md) it requires.
+
+We are not yet publishing plugin code — but many of these are intended to become open source.  
+
+**Examples under exploration:**
+- **ProofMode app** — bundles multiple signals (photo EXIF, GNSS, Wi-Fi) into verifiable metadata.  
+- **WitnessChain RTT module** — measures network round-trip time for co-location proofs.  
+- **Cell ID lookup** — matches detected towers against reference DBs.  
+- **Wi-Fi lookup** — same, but for Wi-Fi SSIDs.  
+- **IMU fusion** — transforms accelerometer/gyroscope traces into motion/location context.  
+- **Geodnet wrapper** — consumes DePIN GNSS corrections as a signal.  
+
+Over time, each plugin will have its own reference page documenting usage, trust model, and outputs.
+
+
+⸻
+
+recipes/index.md
+
+# Location Proof Recipes
+
+A **recipe** is a combination of [plugins](../plugins/index.md) that together form a **multifactor location proof**.
+
+Recipes describe:
+- Which plugins are combined.
+- How evidence is weighted or corroborated.
+- What use case they serve.
+
+**Early examples:**
+- **VPN detection**: IP/ASN + RTT latency + device attestation.  
+- **Physical device localization**: GNSS + Wi-Fi + Cell ID + OS integrity token.  
+- **Supply chain site verification**: Legal doc + GNSS + sensor log.  
+- **Validator co-location (DePIN)**: Network RTT + beacon proximity.  
+
+This section will grow into detailed blueprints, but for now it captures the intent and early directions.
+
+
+⸻
+
+glossary.md
+
+# Glossary
+
+Quick definitions with links:
+
+- **Location stamp** — a discrete, verifiable signal of where/when something happened.  
+- **Location proof** — a combination of stamps verified together. See [Recipes](./recipes/index.md).  
+- **Strategy** — top-level category of how location is derived. See [Strategies](./strategies/index.md).  
+- **Signal** — raw observable used as evidence. See [Signals](./signals/index.md).  
+- **Plugin** — implementation that transforms signals into signed stamps. See [Plugins](./plugins/index.md).  
+- **Recipe** — composition of plugins into multifactor proofs. See [Recipes](./recipes/index.md).  
+- **Integrity assurance** — mechanism that increases confidence in a signal or plugin. See [Integrity](./integrity/index.md).  
+- **Device / OS** — platforms where signals can be captured and integrity applied. See [Device / OS](./device-os/index.md).  
+
diff --git a/docs/location-proofs/device-os/index.md b/docs/location-proofs/device-os/index.md
new file mode 100644
index 0000000..6f6e1ed
--- /dev/null
+++ b/docs/location-proofs/device-os/index.md
@@ -0,0 +1,9 @@
+# Overview
+
+Devices and operating systems determine which [signals](../signals/index.md) are accessible, and what [integrity assurances](../integrity/index.md) are available.
+
+**High-level notes:**
+- **Android**: Broadest access to raw signals (GNSS, Wi-Fi, Bluetooth, IMU). Supports Play Integrity API.
+- **iOS**: More restricted APIs, but includes App Attest and Secure Enclave for integrity.
+- **IoT / Linux boards**: Flexible access, but security posture depends heavily on hardware and software configuration.
+
diff --git a/docs/location-proofs/glossary.md b/docs/location-proofs/glossary.md
new file mode 100644
index 0000000..3c74c44
--- /dev/null
+++ b/docs/location-proofs/glossary.md
@@ -0,0 +1,12 @@
+# Glossary
+
+Quick definitions with links:
+
+- **Location stamp** — a discrete, verifiable signal of where/when something happened.
+- **Location proof** — a combination of stamps verified together. See [Recipes](./recipes/index.md).
+- **Strategy** — top-level category of how location is derived. See [Strategies](./strategies/index.md).
+- **Signal** — raw observable used as evidence. See [Signals](./signals/index.md).
+- **Plugin** — implementation that transforms signals into signed stamps. See [Plugins](./plugins/index.md).
+- **Recipe** — composition of plugins into multifactor proofs. See [Recipes](./recipes/index.md).
+- **Integrity assurance** — mechanism that increases confidence in a signal or plugin. See [Integrity](./integrity/index.md).
+- **Device / OS** — platforms where signals can be captured and integrity applied. See [Device / OS](./device-os/index.md).
\ No newline at end of file
diff --git a/docs/location-proofs/integrity/index.md b/docs/location-proofs/integrity/index.md
new file mode 100644
index 0000000..4f7f83b
--- /dev/null
+++ b/docs/location-proofs/integrity/index.md
@@ -0,0 +1,15 @@
+# Overview
+
+Integrity assurances are **mechanisms that increase trust** in a signal or plugin.
+They are not signals themselves but modifiers of credibility.
+
+Examples under study:
+- **Android Play Integrity API** — attests to app and device state.
+- **Apple App Attest** — verifies iOS app legitimacy.
+- **Trusted Execution Environments (TEE)** — enclaves like TrustZone, SGX, Secure Enclave.
+- **Hardware-backed keys** — signing with embedded secure elements.
+- **Secure boot chains** — device starts in a verified state.
+- **C2PA content credentials** — media provenance.
+- **Timestamp notaries** — external time anchors.
+
+Future pages will expand these into detailed references.
\ No newline at end of file
diff --git a/docs/location-proofs/overview.md b/docs/location-proofs/overview.md
new file mode 100644
index 0000000..a66d310
--- /dev/null
+++ b/docs/location-proofs/overview.md
@@ -0,0 +1,132 @@
+# Overview
+
+Location is one of the most common — and most contested — facts in digital systems.  
+From VPN checks and border control to carbon monitoring and sanctions enforcement,  
+many questions online boil down to **where and when did an event occur?**
+
+Today, location evidence is handled inconsistently:  
+- **Web2** relies on IP addresses, GPS coordinates, billing info, or ad-hoc service logs.  
+- **Web3** systems rarely integrate location at all, despite consensus networks depending on *where nodes are run* and *where users interact*.  
+
+These mechanisms are fragile, fragmented, and easy to manipulate. A ship turning off its AIS transponder, a user masking their IP with a VPN, or a falsified invoice — each shows how weak single-source location evidence can be.
+
+---
+
+## Why Location Proofs?
+
+Our motivation comes from three converging forces:
+
+- **Web3 design principles.** The decentralized web is meant to be *open, durable, and opt-in*. If location is to matter in Web3, it needs to follow these same principles — portable, user-controlled, and verifiable without reliance on a single gatekeeper.  
+- **Verifiability in an age of AI.** Generative AI and cheap spoofing reduce the cost of lying. Stronger proofs of *where and when* something happened raise the cost back up, restoring trust.  
+- **An open framework.** Location affects everyone, everywhere. A proprietary patchwork of APIs won’t do. By building open standards and open-source implementations, we create a foundation that others can inspect, build on, and improve. This makes the system harder to capture, more likely to interoperate, and more durable over time.
+
+---
+
+## Design Goals
+
+- **Pragmatism.** Build on what works today; aim for “good enough” in real systems rather than chasing theoretical perfection.  
+- **Privacy & consent.** Default to user-controlled data, introduce privacy-preserving mechanisms wherever possible, and set developer patterns that encourage restraint.  
+- **Composability.** Proofs should be stackable — independent stamps combined into stronger artifacts.  
+- **Simplicity.** Make it easy for developers to create, verify, and consume proofs. Minimize friction in common flows.  
+- **Interoperability.** Standardize the schema and verification flow so proofs from different systems can coexist and be reused across contexts.  
+- **Accountable persistence.** Proofs should remain verifiable for their intended lifetime, but also support expiry or revocation when privacy, consent, or regulation requires it.
+
+---
+
+## Claims, Stamps, and Proofs
+
+A **location claim** is any assertion about the position — and optionally the time — of a person, device, asset, or event.  
+
+A **location stamp** is a single piece of evidence that corroborates a claim. Examples include:
+- a GPS reading,  
+- a Wi-Fi SSID lookup,  
+- a notarized document,  
+- or an NFC check-in.  
+
+Each stamp makes lying a bit harder — but alone, each can be forged.
+
+A **location proof** combines multiple independent stamps into a verifiable artifact. The principle: **independent evidence increases confidence in the claim.** Forging two or three unrelated signals together is much harder than spoofing one.  
+
+Proofs lie on a *spectrum of certainty*, from weak, single-signal evidence up to high-rigor, multi-signal attestations hardened against even nation-state adversaries. Our framework is designed to harmonize the broad range of evidence types, and package it up into a new internet primitive. 
+
+If we do this well, location proofs will serve use cases ranging from lower stakes — like gaming and social networking — up to ones with higher security requirements, like those in supply chain management, conflict + humanitarian, and compliance.
+
+:::info How Astral Relates to Other Proof-of-Location Systems
+Astral does not compete with systems like WitnessChain, FOAM, or GEODNET.  
+
+Instead, **Astral location proofs sit a layer above**: these systems provide strong stamps that can stand alone or be combined with other, uncorrelated signals to strengthen a claim.  
+
+The Astral framework **harmonizes how such evidence is structured, signed, and verified**, so evidence from different systems can interoperate and developers can compose these signals more easily.
+:::
+
+---
+
+## Core Concepts
+
+- **Strategies** — categories of how location signals can be derived (e.g. machine identifiers, network measurements, delegated records, legal documents).  
+- **Location Signals** — raw observables (e.g. cell IDs, RTT latencies, acoustic or imaging data, EXIF tags).  
+- **Location Stamp Plugins** — software modules that process signals into verifiable location stamps.  
+- **Location Proof Recipes** — multi-plugin compositions that stack location stamps into full proofs.  
+- **Integrity assurances** — cross-cutting mechanisms (e.g. TEEs, OS attestation, hardware signing) that raise confidence in stamps.  
+- **Location Protocol** — a standardized schema for structuring, signing, and transporting spatial data, so stamps and proofs remain portable, verifiable, and interoperable across systems — the envelope for location proofs.
+
+---
+
+## Location Proof Lifecycle
+
+At a high level, the lifecycle of a proof follows this pipeline:
+
+1. **Signals observed** — raw data from devices, networks, or documents.  
+2. **On-device processing** — signals fused, normalized, or pre-validated.  
+3. **Integrity checks** — assurance that the data comes from trusted hardware, OS, or environment.  
+4. **Signing** — a plugin packages the evidence into a structured, signed location stamp.  
+5. **Verification** — multiple stamps are combined into a recipe, checked for independence and consistency, yielding a location proof.
+
+Note that some plugins may deviate from this exact process — but it's a useful high-level mental model. 
+
+---
+
+## Why Now?
+
+Several converging trends make location proofs urgent:
+
+1. **Web3 design principles** — open, durable, opt-in. Decentralized apps need portable, verifiable evidence of location, just like they need portable, verifiable identity.  
+2. **Web2 messiness** — today’s geolocation methods are fragmented and rarely auditable.  
+3. **Regulation & compliance** — data residency, sanctions, KYC/AML: all are location-dependent.  
+4. **AI & disinformation** — deepfakes, spoofing, and generative content lower the cost of lying; stronger proofs raise it.  
+5. **Splinternet pressures** — as jurisdictions diverge, verifiable location metadata can enable technical enforcement of locally-scoped rules.
+
+---
+
+## Astral’s Work
+
+At Astral, in collaboration with the University of Maryland and OGC, we are:  
+
+- **Cataloging strategies and signals** — mapping the landscape of how location evidence can be produced.  
+- **Building plugins and recipes** — creating open-source modules that turn signals into stamps and proofs.  
+- **Developing the Location Protocol** — an interoperable schema for location attestations, the common data format that makes proofs portable and verifiable.  
+- **Exploring use cases** — from wallet security and fraud detection to carbon monitoring, AI localization, and supply chain compliance.
+
+---
+
+## Next Steps in this Section
+
+- [Strategies](../strategies/index.md): categories of how location evidence is produced.
+- [Signals](../signals/index.md): raw observables we can build from.
+- [Integrity](../integrity/index.md): cross-cutting assurances.
+- [Plugins](../plugins/index.md): modules that generate verifiable stamps.
+- [Recipes](../recipes/index.md): compositions of multiple plugins into full proofs.
+
+---
+
+## Get Involved
+
+Location proofs are an evolving research area. We welcome collaboration, feedback, and contributions from researchers, developers, and organizations working on location verification challenges.
+
+**Connect with us:**
+- **GitHub**: [github.com/DecentralizedGeo](https://github.com/DecentralizedGeo) — contribute to open-source implementations
+- **Telegram**: [Join our community](https://t.me/+UkTOSXnDcDM5ZTBk) — discuss research and applications
+- **Twitter**: [@astralprotocol](https://twitter.com/astralprotocol) — follow updates and announcements
+
+---
+
diff --git a/docs/location-proofs/plugins/index.md b/docs/location-proofs/plugins/index.md
new file mode 100644
index 0000000..75bc116
--- /dev/null
+++ b/docs/location-proofs/plugins/index.md
@@ -0,0 +1,13 @@
+# Overview
+
+**Plugins** are implementations that transform raw [signals](../signals/index.md) into verifiable **location stamps**.
+Each plugin references the signals it uses, the [devices/OS](../device-os/index.md) it runs on, and any [integrity assurances](../integrity/index.md) it requires.
+
+**Examples under exploration:**
+- **ProofMode app** — bundles multiple signals (photo EXIF, GNSS, Wi-Fi) into verifiable metadata.
+- **WitnessChain RTT module** — measures network round-trip time for co-location proofs.
+- **Cell ID lookup** — matches detected towers against reference DBs.
+- **Wi-Fi lookup** — same, but for Wi-Fi SSIDs.
+- **IMU fusion** — transforms accelerometer/gyroscope traces into motion/location context.
+
+Over time, each plugin will have its own reference page documenting usage, trust model, and outputs.G
\ No newline at end of file
diff --git a/docs/location-proofs/recipes/index.md b/docs/location-proofs/recipes/index.md
new file mode 100644
index 0000000..d64fb19
--- /dev/null
+++ b/docs/location-proofs/recipes/index.md
@@ -0,0 +1,16 @@
+# Overview
+
+A **recipe** is a combination of [plugins](../plugins/index.md) that together form a **multifactor location proof**.
+
+Recipes describe:
+- Which plugins are combined.
+- How evidence is weighted or corroborated.
+- What use case they serve.
+
+**Early examples:**
+- **VPN detection**: IP/ASN + RTT latency + device attestation.
+- **Physical device localization**: GNSS + Wi-Fi + Cell ID + OS integrity token.
+- **Supply chain site verification**: Legal doc + GNSS + sensor log.
+- **Validator co-location (DePIN)**: Network RTT + beacon proximity.
+
+This section will grow into detailed blueprints, but for now it captures the intent and early directions.
\ No newline at end of file
diff --git a/docs/location-proofs/signals/index.md b/docs/location-proofs/signals/index.md
new file mode 100644
index 0000000..39fdaf3
--- /dev/null
+++ b/docs/location-proofs/signals/index.md
@@ -0,0 +1,23 @@
+# Overview
+
+This section will contain **raw signals**, categorized under the [strategies](../strategies/index.md).
+Signals are the **observables** that plugins can transform into verifiable stamps.
+
+For now, we treat this as a **research agenda**: a living list of signals we intend to document.
+
+| Signal | Strategy | Context |
+|--------|----------|---------|
+| GNSS pseudoranges | Network Measurements | Core satellite navigation raw values |
+| Wi-Fi SSID/BSSID | Machine Identifiers | Device-visible broadcast IDs |
+| Bluetooth MACs | Machine Identifiers | Short-range device identifiers |
+| Cell IDs | Machine Identifiers | Tower IDs used by carriers |
+| IP / ASN | Machine Identifiers | Reported by network layer |
+| RTT latency | Network Measurements | Round-trip time between nodes |
+| RSSI trilateration | Network Measurements | Signal strength analysis for range |
+| Inertial IMU | Sensor Data | Accelerometer/gyroscope traces |
+| Microphone acoustics | Sensor Data | Ambient sound signatures |
+| Camera EXIF | Sensor Data | Embedded photo metadata |
+| Delegated datasets | Delegated | Uber ride, bank statement, utility bill |
+| Legal documents | Legal | Bills of lading, customs docs, affidavits |
+
+Each entry will eventually have its own page. For now, this list signals where research is headed.
\ No newline at end of file
diff --git a/docs/location-proofs/strategies/authority.md b/docs/location-proofs/strategies/authority.md
new file mode 100644
index 0000000..5134582
--- /dev/null
+++ b/docs/location-proofs/strategies/authority.md
@@ -0,0 +1,19 @@
+# Authority
+
+**Definition:**  
+Location evidence provided by an individual or organization acting in a *privileged or trusted role*.  
+Unlike [Social](./social.md) attestations, where peers vouch for each other, Authority attestations come from gatekeepers or officials recognized to have asymmetric credibility.
+
+**Examples:**  
+- A border control officer stamping a passport at entry/exit.  
+- An event host scanning and recording ticket check-ins.  
+- A surveyor or notary signing a certificate of presence.  
+- A customs officer recording inspection of goods.  
+
+**Derivation method:**  
+A person in an official role issues an attestation tied to place (and often time). The verifier trusts the claim because of the authority vested in the role, not the number of peers.
+
+**Risks:**  
+- Centralized trust in institutions or roles.  
+- Potential for abuse, coercion, or corruption.  
+- Often requires disclosure of identity, which can raise privacy concerns.  
\ No newline at end of file
diff --git a/docs/location-proofs/strategies/delegated.md b/docs/location-proofs/strategies/delegated.md
new file mode 100644
index 0000000..0853043
--- /dev/null
+++ b/docs/location-proofs/strategies/delegated.md
@@ -0,0 +1,16 @@
+# Delegated
+
+**Definition:**
+Location evidence derived from data held by a trusted third-party service.
+
+**Examples:**
+- Uber ride logs
+- Mobile carrier call detail records (CDRs)
+- Utility bills
+- Bank transaction metadata
+
+**Derivation method:**
+Delegated service provides a record → verifier checks consistency and origin.
+
+**Risks:**
+Centralized trust dependency. Privacy and data access constraints.
\ No newline at end of file
diff --git a/docs/location-proofs/strategies/index.md b/docs/location-proofs/strategies/index.md
new file mode 100644
index 0000000..d9172f8
--- /dev/null
+++ b/docs/location-proofs/strategies/index.md
@@ -0,0 +1,16 @@
+# Overview
+
+**Strategies** are broad categories of how location signals can be derived.
+They provide the conceptual map under which specific [signals](../signals/index.md) are organized.
+
+The seven strategies we track:
+
+- [Machine Identifiers](./machine-identifiers.md)
+- [Network Measurements](./network-measurements.md)
+- [Sensor Data](./sensor-data.md)
+- [Delegated](./delegated.md)
+- [Social](./social.md)
+- [Authority](./authority.md)
+- [Legal](./legal.md)
+
+Each strategy page gives a concise definition and typical examples.
\ No newline at end of file
diff --git a/docs/location-proofs/strategies/legal.md b/docs/location-proofs/strategies/legal.md
new file mode 100644
index 0000000..05caf45
--- /dev/null
+++ b/docs/location-proofs/strategies/legal.md
@@ -0,0 +1,19 @@
+# Legal
+
+**Definition:**  
+Location evidence embedded in formal legal instruments where the claimant is directly accountable under law.  
+Unlike [Delegated](./delegated.md) records (which are service or registry data), Legal proofs are created when a person or entity **signs a statement of location** that would be legally punishable if false.
+
+**Examples:**  
+- A sworn affidavit: “I was present at this place and time.”  
+- A court filing that specifies location of an event or asset.  
+- A notarized declaration of presence.  
+- Customs or shipping declarations signed under penalty of law.  
+
+**Derivation method:**  
+The claimant (or their representative) signs a legally binding document that includes a location claim. Verification relies on the legal system’s enforcement of perjury and fraud statutes.
+
+**Risks:**  
+- Depends heavily on jurisdiction and enforcement.  
+- Can be slow and bureaucratic to obtain.  
+- False claims are still possible if enforcement is weak or corruption is present.  
\ No newline at end of file
diff --git a/docs/location-proofs/strategies/machine-identifiers.md b/docs/location-proofs/strategies/machine-identifiers.md
new file mode 100644
index 0000000..245d9f7
--- /dev/null
+++ b/docs/location-proofs/strategies/machine-identifiers.md
@@ -0,0 +1,17 @@
+# Machine Identifiers
+
+**Definition:**
+Location derived by detecting machine identifiers and comparing them with a georeferenced lookup table.
+
+**Examples:**
+- Wi-Fi SSIDs and BSSIDs
+- Bluetooth MAC addresses
+- Cell tower IDs
+- IP addresses / ASNs
+- DePIN beacons (e.g., Helium)
+
+**Derivation method:**
+Observed identifiers → cross-reference against a known dataset → location estimate.
+
+**Risks:**
+Identifiers can be cloned or replayed. Databases may be stale or incomplete.
\ No newline at end of file
diff --git a/docs/location-proofs/strategies/network-measurements.md b/docs/location-proofs/strategies/network-measurements.md
new file mode 100644
index 0000000..5a13193
--- /dev/null
+++ b/docs/location-proofs/strategies/network-measurements.md
@@ -0,0 +1,17 @@
+# Network Measurements
+
+**Definition:**
+Location derived from measured values produced by network interactions.
+
+**Examples:**
+- GNSS pseudoranges (satellite timing)
+- RTT / latency between nodes
+- WitnessChain co-location checks
+- Proximum timing proofs
+- RSSI trilateration (signal strength)
+
+**Derivation method:**
+Measured values → compute position using physics or geometry.
+
+**Risks:**
+Measurements can be manipulated (signal jamming, GNSS spoofing, latency injection).
\ No newline at end of file
diff --git a/docs/location-proofs/strategies/sensor-data.md b/docs/location-proofs/strategies/sensor-data.md
new file mode 100644
index 0000000..1ce4684
--- /dev/null
+++ b/docs/location-proofs/strategies/sensor-data.md
@@ -0,0 +1,16 @@
+# Sensor Data
+
+**Definition:**
+Location context inferred from raw sensor readings produced by a device.
+
+**Examples:**
+- Inertial sensors (IMU: accelerometer, gyroscope)
+- Microphone acoustics
+- Camera EXIF or image content
+- LiDAR or depth sensors
+
+**Derivation method:**
+Raw sensor traces → pattern matching or model analysis → location context.
+
+**Risks:**
+Sensors can be noisy, biased, or deliberately spoofed (e.g., replayed images, synthetic audio).
\ No newline at end of file
diff --git a/docs/location-proofs/strategies/social.md b/docs/location-proofs/strategies/social.md
new file mode 100644
index 0000000..981416e
--- /dev/null
+++ b/docs/location-proofs/strategies/social.md
@@ -0,0 +1,15 @@
+# Social
+
+**Definition:**
+Location evidence generated through attestations by peers or communities.
+
+**Examples:**
+- Witness signatures (friends confirming co-presence)
+- Crowdsourced validation of events or assets
+- Community mapping projects
+
+**Derivation method:**
+Multiple independent social attestations → combined into a verifiable record.
+
+**Risks:**
+Sybil attacks (fake identities), collusion, and subjective bias.
\ No newline at end of file
diff --git a/docs/location-proofs/templates/integrity.md b/docs/location-proofs/templates/integrity.md
new file mode 100644
index 0000000..5621ebc
--- /dev/null
+++ b/docs/location-proofs/templates/integrity.md
@@ -0,0 +1,18 @@
+# [Integrity Mechanism Name]
+
+**Type:** [e.g., Hardware attestation, Software verification, Cryptographic proof]
+
+**Description:**
+[What this mechanism provides and how it works]
+
+**Platforms:**
+[Which devices/OS support this mechanism]
+
+**Implementation:**
+[Technical details of how to use this mechanism]
+
+**Trust model:**
+[What assumptions are required for this to be trusted]
+
+**Limitations:**
+[Known weaknesses or scope restrictions]
\ No newline at end of file
diff --git a/docs/location-proofs/templates/plugin.md b/docs/location-proofs/templates/plugin.md
new file mode 100644
index 0000000..61f640d
--- /dev/null
+++ b/docs/location-proofs/templates/plugin.md
@@ -0,0 +1,25 @@
+# [Plugin Name]
+
+**Signals used:**
+- [Signal 1]
+- [Signal 2]
+
+**Output format:**
+[Description of the location stamp format this plugin produces]
+
+**Platforms:**
+[Supported devices/OS]
+
+**Integrity assurances:**
+[What integrity mechanisms this plugin leverages]
+
+**Configuration:**
+[Setup and usage instructions]
+
+**Trust model:**
+[What this plugin assumes about the environment]
+
+**Example output:**
+```
+[Sample location stamp]
+```
\ No newline at end of file
diff --git a/docs/location-proofs/templates/recipe.md b/docs/location-proofs/templates/recipe.md
new file mode 100644
index 0000000..9ae3759
--- /dev/null
+++ b/docs/location-proofs/templates/recipe.md
@@ -0,0 +1,20 @@
+# [Recipe Name]
+
+**Use case:** [What this recipe is designed to prove or detect]
+
+**Plugins required:**
+- [Plugin 1] - [role/weight]
+- [Plugin 2] - [role/weight]
+- [Plugin 3] - [role/weight]
+
+**Combination logic:**
+[How the evidence from different plugins is weighted and combined]
+
+**Confidence levels:**
+[What confidence levels this recipe can achieve]
+
+**Implementation notes:**
+[Practical considerations for deploying this recipe]
+
+**Example scenarios:**
+[Real-world situations where this recipe would be used]
\ No newline at end of file
diff --git a/docs/location-proofs/templates/signal.md b/docs/location-proofs/templates/signal.md
new file mode 100644
index 0000000..ce573d4
--- /dev/null
+++ b/docs/location-proofs/templates/signal.md
@@ -0,0 +1,18 @@
+# [Signal Name]
+
+**Strategy:** [Parent strategy category]
+
+**Description:**
+[What this signal represents and how it's observed]
+
+**Collection method:**
+[How the signal is captured or measured]
+
+**Format:**
+[Data structure/format of the signal]
+
+**Reliability:**
+[Factors affecting signal quality and trustworthiness]
+
+**Use cases:**
+[Typical applications where this signal is useful]
\ No newline at end of file
diff --git a/docs/location-proofs/templates/strategy.md b/docs/location-proofs/templates/strategy.md
new file mode 100644
index 0000000..f4d219c
--- /dev/null
+++ b/docs/location-proofs/templates/strategy.md
@@ -0,0 +1,15 @@
+# [Strategy Name]
+
+**Definition:**
+[Brief description of how location is derived using this strategy]
+
+**Examples:**
+- [Example 1]
+- [Example 2]
+- [Example 3]
+
+**Derivation method:**
+[Input] → [process] → [location output]
+
+**Risks:**
+[Main vulnerabilities and limitations of this approach]
\ No newline at end of file
diff --git a/sidebars.ts b/sidebars.ts
index af06a2c..c7398b4 100644
--- a/sidebars.ts
+++ b/sidebars.ts
@@ -1,76 +1,79 @@
 const sidebars = {
   docs: [
     {
-      type: 'doc',
-      id: 'introduction',
+      type: 'category',
       label: 'Astral',
+      items: [
+        'introduction',
+        {
+          type: 'category',
+          label: 'Core Concepts',
+          items: [
+            'core-concepts/what-is-spatial-data',
+            'core-concepts/location-proofs',
+            'core-concepts/onchain-geospatial',
+            'core-concepts/decentralized-spatial-data',
+          ],
+        },
+      ],
     },
     {
       type: 'category',
-      label: 'SDK',
+      label: 'Location Proofs',
       items: [
-        'sdk/index',
+        'location-proofs/overview',
         {
           type: 'category',
-          label: 'Quick Start',
+          label: 'Strategies',
           items: [
-            'sdk/quick-start/index',
-            'sdk/quick-start/installation',
-            'sdk/quick-start/configuration',
-            'sdk/quick-start/first-attestation',
+            'location-proofs/strategies/index',
+            'location-proofs/strategies/machine-identifiers',
+            'location-proofs/strategies/network-measurements',
+            'location-proofs/strategies/sensor-data',
+            'location-proofs/strategies/delegated',
+            'location-proofs/strategies/social',
+            'location-proofs/strategies/authority',
+            'location-proofs/strategies/legal',
           ],
         },
         {
           type: 'category',
-          label: 'Core Concepts',
+          label: 'Signals',
           items: [
-            'sdk/core-concepts/index',
-            'sdk/background/web3',
-            'sdk/background/geospatial',
+            'location-proofs/signals/index',
           ],
         },
         {
           type: 'category',
-          label: 'Guides',
+          label: 'Integrity',
           items: [
-            'sdk/guides/getting-started',
-            'sdk/guides/offchain-workflow',
-            'sdk/guides/onchain-workflow',
-            'sdk/guides/development',
+            'location-proofs/integrity/index',
           ],
         },
         {
           type: 'category',
-          label: 'Extensions',
+          label: 'Device / OS',
           items: [
-            'sdk/extensions',
+            'location-proofs/device-os/index',
           ],
         },
-      ]
-    },
-    {
-      type:'category',
-      label: 'API',
-      items: [
-        'api/getting-started',
-        'api/authentication',
-        'api/data-model',
-        'api/graphql-api',
-        'api/ogc-api',
-        'api/api-reference',
-        'api/troubleshooting'
-      ]
+        {
+          type: 'category',
+          label: 'Plugins',
+          items: [
+            'location-proofs/plugins/index',
+          ],
+        },
+        {
+          type: 'category',
+          label: 'Recipes',
+          items: [
+            'location-proofs/recipes/index',
+          ],
+        },
+        'location-proofs/glossary',
+      ],
     },
-    // {
-    //   type: 'category',
-    //   label: 'Core Concepts',
-    //   items: [
-    //     'core-concepts/what-is-spatial-data',
-    //     'core-concepts/location-proofs',
-    //     'core-concepts/onchain-geospatial',
-    //     'core-concepts/decentralized-spatial-data',
-    //   ],
-    // },
     {
       type: 'category',
       label: 'Location Protocol',
@@ -86,23 +89,77 @@ const sidebars = {
     },
     {
       type: 'category',
-      label: 'Spatial.sol',
+      label: 'Developer Tools',
       items: [
-        'spatial-sol/introduction',
-        'spatial-sol/research-plan',
-      ],
-    },
-    {
-      type: 'category',
-      label: 'Astralscan',
-      items: [
-        'astralscan/introduction',
-        'astralscan/registering-entries',
-        'astralscan/viewing-entries',
-        'astralscan/multi-entry-views',
-        'astralscan/frames',
-        'astralscan/developers',
-        'astralscan/contributing',
+        {
+          type: 'category',
+          label: 'API',
+          items: [
+            'api/getting-started',
+            'api/authentication',
+            'api/data-model',
+            'api/graphql-api',
+            'api/ogc-api',
+            'api/api-reference',
+            'api/troubleshooting'
+          ]
+        },
+        {
+          type: 'category',
+          label: 'SDK',
+          items: [
+            'sdk/index',
+            {
+              type: 'category',
+              label: 'Quick Start',
+              items: [
+                'sdk/quick-start/index',
+                'sdk/quick-start/installation',
+                'sdk/quick-start/configuration',
+                'sdk/quick-start/first-attestation',
+              ],
+            },
+            {
+              type: 'category',
+              label: 'Core Concepts',
+              items: [
+                'sdk/core-concepts/index',
+                'sdk/background/web3',
+                'sdk/background/geospatial',
+              ],
+            },
+            {
+              type: 'category',
+              label: 'Guides',
+              items: [
+                'sdk/guides/getting-started',
+                'sdk/guides/offchain-workflow',
+                'sdk/guides/onchain-workflow',
+                'sdk/guides/development',
+              ],
+            },
+            {
+              type: 'category',
+              label: 'Extensions',
+              items: [
+                'sdk/extensions',
+              ],
+            },
+          ]
+        },
+        {
+          type: 'category',
+          label: 'Astralscan',
+          items: [
+            'astralscan/introduction',
+            'astralscan/registering-entries',
+            'astralscan/viewing-entries',
+            'astralscan/multi-entry-views',
+            'astralscan/frames',
+            'astralscan/developers',
+            'astralscan/contributing',
+          ],
+        },
       ],
     },
     {
@@ -112,6 +169,14 @@ const sidebars = {
         'research/introduction',
       ],
     },
+    // {
+    //   type: 'category',
+    //   label: 'Spatial.sol',
+    //   items: [
+    //     'spatial-sol/introduction',
+    //     'spatial-sol/research-plan',
+    //   ],
+    // },
   ],
 };