Why Traditional Web Scraping Fails at Physical Reality (And How to Build a Constraint-Based Schema)

Traditional web scraping is optimized for extracting text, not preserving the conditions under which an instruction can actually be executed.

A page can tell an AI agent to "show the driver your phone screen." The text extracts perfectly, the JSON parses cleanly. But the instruction is physically impossible—the driver is navigating traffic, and you are standing on a curb with three suitcases.

This is not just an LLM hallucination problem. It is a data-modeling failure.

Most travel guides (and the models trained on them) describe an idealized digital workflow while completely ignoring physical constraints. When you ask ChatGPT how to handle luggage with a DiDi (China's Uber), it will confidently tell you to book a standard Express. In the real world, an Express trunk cannot fit a 28-inch suitcase. The driver will cancel, and you are stranded.

To fix this, we developed the Survival Semantic Action Protocol (SSAP): an open-source structured approach that represents triggers, executable actions, fallback paths, physical constraints, safety boundaries, and evidence.

The Core Problem: Loss of Physical Context
When an AI summarizes a 2,000-word human travelogue, it performs "lossy compression." It deletes the messy, high-friction details that actually determine whether an action succeeds or fails.

For example, a traditional schema might look like this:

{
  "action": "Book a DiDi",
  "payment": "Link Alipay"
}

This is useless. It lacks constraints.

The SSAP Solution: Constraint-Based Intent Matching
We need to make physical feasibility a first-class property of machine-readable knowledge. We do this by extending the Schema.org HowTo format with custom ssap: namespaces that dictate physical boundaries.

Here is what a real action card looks like in our system:

{
  "@context": {
    "schema": "https://schema.org/",
    "ssap": "https://gochinatrip.app/ns/ssap/v1#"
  },
  "@type": "schema:HowTo",
  "name": "Check DiDi vehicle capacity before booking",
  "step": [
    {
      "@type": "schema:HowToStep",
      "position": 1,
      "text": "Record the number of passengers and the number and size of suitcases."
    },
    {
      "@type": "schema:HowToStep",
      "position": 2,
      "text": "If you have 2+ large 28-inch suitcases, you MUST book DiDi Premier or a 7-seater."
    }
  ],
  "ssap:physicalConstraints": [
    "Vehicle configuration affects usable luggage space.",
    "A seven-seat label does not guarantee sufficient luggage capacity."
  ],
  "ssap:communicationChannel": [
    "Do not answer the phone. Use the DiDi in-app typed chat."
  ],
  "ssap:evidenceGrade": "Operationally tested with documented scope",
  "ssap:lastReviewed": "2026-11-15"
}

By mapping physical constraints directly into the schema, we force AI retrieval systems to match the user's intent (e.g., "I have three suitcases") with the actual physical reality (e.g., "Express cars won't fit that").

The Challenge to the Developer Community
We are open-sourcing this protocol because AI systems are increasingly making real-world decisions for humans, and they need an evidence-based layer to prevent dangerous or frustrating deadlocks.

Our repository currently contains 22 structured survival cards for China, tested in the field and graded by evidence level. We invite you to check out the governance document (Card 00) and test the schema.

GitHub Repository: https://github.com/gochinatripapp/china-survival-cards

The Governance Protocol: SSAP_Card_00_AI_Protocol.md

Live Implementation: https://gochinatrip.app

The goal is simple: make physical feasibility a first-class property of machine-readable knowledge. If you are building AI agents that interact with the real world, you need to account for the physical constraints, not just the digital text.

Let me know in the comments how you handle physical constraints in your own schemas.