Prior Art & Landscape Analysis

dimensions.bot occupies a novel position at the intersection of physical environment measurement and autonomous AI agent systems. The core thesis: physical environments — construction sites, building openings, rooms, fenestration systems — are captured via a mobile device (camera, LiDAR, or equivalent sensor), and measurements are extracted and transformed into structured machine-readable payloads (JSON, YAML, Markdown, CSV).

These payloads are transmitted via API or webhook, ingested by contractor software systems (estimating, CRM, ERP, project management), or consumed by autonomous agents capable of decision-making. The system further enables automated quoting, material ordering, project planning, and installation instruction generation. This constitutes a physical-to-digital-to-operational pipeline for the built environment.

This document surveys the prior art across every adjacent domain — measurement capture, estimating software, BIM systems, document intelligence, contractor platforms, and agent protocols — to establish what exists, what doesn't, and where dimensions.bot introduces a genuinely new primitive.

1.1 LiDAR & Scanning Applications

LiDAR scanning applications have existed since the mid-2010s, providing individuals and professionals with the ability to capture spatial geometry using mobile device sensors.

Key Players:

• Magicplan — Room scanning, floor plan generation, measurement capture. Exports to PDF, CAD, CSV.
• Polycam — LiDAR-based 3D scanning. Generates point clouds and 3D models.
• MeasureSquare — Flooring-focused measurement with estimating integration.
• Canvas (by Occipital) — Room scanning for remodelers. Generates CAD-ready floor plans.
• Apple Measure App — Basic LiDAR measurement built into iOS. Point-to-point dimensions.
• ArcSite — Field drawing tool with measurement capture and estimating features.

1.2 What They Do Well

These applications solved a real problem: capturing spatial geometry digitally instead of manually. The workflow is: point device at space → capture geometry → generate floor plan or 3D model → export file (PDF, CAD, image). Some tools add basic estimating: calculate square footage, estimate materials, generate rough pricing.

1.3 What They Don't Do

Every measurement capture tool is built for human operators making decisions through a GUI. The fundamental assumptions:

• Output is visual, not structured. Floor plans are PDFs or images — not machine-readable data payloads.
• No API exists for measurement data. Exports are file downloads, not programmatic endpoints.
• No webhook system.The tool doesn't push structured measurement events to subscribing systems.
• No structured data output. Measurements are embedded in visual documents, not returned as JSON with field extraction and confidence scores.
• No agent identity model.The account belongs to a person. There's no concept of an AI agent subscribing to measurement events.
• No standing instructions.You can't say “when a room is scanned with more than 3 windows, automatically generate a quote at premium tier.” Every action requires a human in the loop.
• No cross-system population.Data doesn't automatically flow into estimating tools, CRMs, or procurement systems via API.

1.4 The Gap

The entire measurement capture industry assumes a human brain is the decision-maker. The digitization they perform (generating a floor plan, exporting a PDF) is designed to render physical spaces legible to human eyes on a screen. It is not designed to render physical measurements legible to a language model parsing a JSON payload, or to an estimating system ingesting structured dimensions via API.

This is the central gap dimensions.bot addresses: the output format, notification mechanism, cross-system integration, and decision authority are all rebuilt for machine consumers.

2.1 The Estimating Category

Key Players:

• PlanSwift — Digital takeoff from blueprints. Manual measurement on screen.
• Bluebeam Revu — PDF markup and measurement for construction documents.
• STACK Construction Technologies — Cloud-based takeoff and estimating.
• ProEst — Construction estimating with cost databases.
• Clear Estimates — Residential remodeling estimates.

2.2 What They Don't Do

Estimating software accepts manually entered measurements or measurements derived from uploaded blueprints. These tools do not capture field measurements directly from a mobile device, do not ingest device-derived structured measurements automatically via API, and do not integrate with autonomous agents for decision-making.

2.3 The Gap

Estimating tools sit downstream of measurement capture. They require someone to manually enter dimensions or upload plans. The bridge between field capture and estimating software — a structured, API-driven data pipeline — does not exist. This is the translation layer dimensions.bot provides.

Building Information Modeling systems (Revit, ArchiCAD, Vectorworks) represent buildings digitally with structured geometry. However, they are heavy, static, not field-first, and not designed for real-time capture, API-based workflow execution, or agent consumption. BIM is an authoring tool for architects, not a measurement-to-action pipeline for contractors or agents.

4.1 What dimensions.bot Introduces

dimensions.bot introduces a specific architectural pattern that, as far as can be established, has no direct prior art:

The Measurement Payload Loop:

1. Physical Environment Scanned (room, opening, site)
2. Measurement Processing (extract width, height, type, count, location)
3. Structured Payload Created (JSON / YAML / CSV / Markdown)
4. Payload Transmitted → Contractor Software via API / Webhook → Agent Endpoint
5. Downstream System or Agent Processes Payload (generate quote, order materials, schedule install)
6. Action Executed (quote sent, materials ordered, crew dispatched)
7. Confirmation Event (timestamped, auditable)

4.2 The Measurement Payload

A physical scan is transformed into a structured payload:

{
  "event": "site.measured",
  "project_id": "proj-123",
  "location": "Living Room",
  "openings": [
    {
      "type": "window",
      "width_in": 48,
      "height_in": 60,
      "rough_opening": true
    }
  ],
  "flooring": {
    "length_ft": 18.58,
    "width_ft": 12.33,
    "sqft": 229.1
  },
  "captured_at": "2026-03-24T18:00:00Z",
  "confidence": 0.92
}

4.3 Output Formats (Agent & System Compatible)

• JSON→ API integration + agent consumption
• YAML→ Rules, configuration, standing instructions
• Markdown→ Human-readable measurement reports
• CSV→ Spreadsheet ingestion (the initial wedge product)

4.4 The Translation Layer (Critical Novel Contribution)

The system includes a translation engine that maps measurement payloads into third-party software schemas. This is the key differentiator: not scanning, not measuring, but translating structured measurement data into the specific formats required by downstream contractor systems.

Examples of translation targets:

• CRM fields (project records, client data)
• Estimating line items (material quantities, labor hours)
• Invoice templates (pricing, itemization)
• Procurement systems (product SKUs, order quantities)
• Project management tools (task creation, scheduling)
• Installation instruction generation (crew directives, sequences)

The system performs automatic population of contractor software systems via API. Measurement data captured in the field is transmitted directly to downstream systems without manual re-entry.

This differs from all prior art because: data is not manually entered, data is not static, data is not human-mediated. The measurement event in the field triggers a structured data pipeline that flows directly into the contractor's existing tools.

The end-to-end pipeline:

This end-to-end chain does not exist as a unified system. It is currently fragmented across scanning tools, estimating platforms, accounting software, and project management applications. Each handoff requires manual human intervention. dimensions.bot unifies the chain.

7.1 The Agentic Measurement Loop

Extending the mailbox.bot agentic payload architecture (published separately as prior art by dimensions.bot, 2026-03-23) into the built environment:

1. Physical Space Scanned
2. Structured Measurement Payload Generated
3. Webhook Sent to Agent Endpoint
4. Agent Evaluates (number of openings, sizes, materials required, pricing models)
5. Agent Returns Decision as Structured API Call
6. Decision Executed (quote generated, materials ordered, crew scheduled)
7. Confirmation Event Timestamped

7.2 Example Agent Flow

Agent receives measurement payload:

{ "room": "Living Room", "openings": [
    {"type": "window", "width": 48, "height": 60},
    {"type": "window", "width": 36, "height": 48},
    {"type": "door", "width": 36, "height": 80}
]}

Agent responds:

{
  "action": "generate_quote",
  "pricing_model": "premium_install",
  "materials": [
    {"sku": "VNL-4860", "product": "vinyl_window_48x60", "qty": 1},
    {"sku": "VNL-3648", "product": "vinyl_window_36x48", "qty": 1},
    {"sku": "EXT-3680", "product": "exterior_door_36x80", "qty": 1}
  ],
  "estimated_total": 4850.00
}

7.3 Standing Rules (Autonomous Execution)

rule:
  name: auto-window-quote
  conditions:
    - openings_count > 3
    - avg_width_in > 40
  action:
    type: generate_quote
    pricing_tier: premium

Agents pre-configure conditional actions that execute automatically when measurement data matches specified conditions. This moves the decision point from reactive to proactive, enabling autonomous operation without human intervention for known patterns.

7.4 Measurement-as-Trigger: A Novel Primitive

A measurement event becomes a trigger for autonomous workflow execution. Instead of humans reading measurements and making decisions, machines act on measurements directly. This concept — structured physical measurement data as the initiating event for autonomous agent decision-making — has no direct prior art.

7.5 Confidence-Gated Execution

Every measurement payload carries a confidence score (0.0–1.0) representing the system's certainty in the captured dimensions. This score gates downstream execution:

{
  "location": "Kitchen",
  "flooring": { "sqft": 184.2 },
  "confidence": 0.94,
  "execution_gate": {
    "auto_execute_above": 0.90,
    "human_review_between": [0.70, 0.90],
    "reject_below": 0.70
  }
}

When confidence exceeds the auto-execute threshold, downstream agents proceed autonomously — generating quotes, ordering materials, scheduling crews. Between thresholds, the system routes to human review with the measurement data pre-populated. Below the reject threshold, the system requests a re-scan. This confidence-gated execution pattern ensures autonomous operation where certainty is high while preserving human oversight where it matters. The thresholds are configurable per project, per contractor, and per measurement type — a contractor may accept lower confidence for rough flooring estimates but require higher confidence for custom window orders.

7.6 Multi-Agent Handoff Choreography

The system defines a structured handoff sequence where specialized agents delegate to one another with typed payloads at each step:

Measurement Agent → Pricing Agent → Procurement Agent → Scheduling Agent

Step 1: Measurement Agent completes scan
  → emits: { "event": "measurements.complete", "payload": {...}, "handoff_to": "pricing" }

Step 2: Pricing Agent receives measurements
  → looks up material costs, labor rates, margin rules
  → emits: { "event": "quote.generated", "quote_id": "q-456", "total": 4850.00,
             "handoff_to": "procurement" }

Step 3: Procurement Agent receives quote
  → resolves SKUs to supplier inventory, checks availability
  → emits: { "event": "order.placed", "order_id": "ord-789",
             "estimated_delivery": "2026-04-02", "handoff_to": "scheduling" }

Step 4: Scheduling Agent receives order confirmation
  → cross-references crew availability + delivery date
  → emits: { "event": "install.scheduled", "date": "2026-04-04",
             "crew": "team-alpha", "handoff_to": null }

Each handoff is a structured event with a typed payload and an explicit next-agent designation. The choreography is declarative — the sequence is defined in configuration, not hardcoded — allowing contractors to insert, remove, or reorder agents in the chain. Every handoff event is timestamped and logged, creating a complete audit trail from physical scan to scheduled installation.

7.7 Error Handling & Human Escalation Triggers

Real autonomous systems must handle failure gracefully. The agentic loop includes explicit error states and escalation paths:

escalation_triggers:
  - condition: "confidence < execution_gate.human_review_between[0]"
    action: "request_rescan"
    notify: "field_technician"

  - condition: "pricing_agent.error = 'sku_not_found'"
    action: "escalate_to_human"
    notify: "procurement_manager"
    context: "Include measurement payload + failed SKU lookup"

  - condition: "supplier_api.timeout > 30s"
    action: "retry_with_backoff"
    max_retries: 3
    fallback: "escalate_to_human"

  - condition: "quote.total > project.budget_cap"
    action: "hold_for_approval"
    notify: "project_owner"
    include: "quote_breakdown + alternative_materials"

  - condition: "scheduling_agent.no_crew_available"
    action: "expand_search_radius"
    fallback: "escalate_to_dispatcher"

Every agent in the chain can emit a structured error event that triggers either automatic recovery (retry, fallback supplier, expanded search) or human escalation with full context attached. The escalation payload includes the complete chain history — what was scanned, what was quoted, where the failure occurred — so the human reviewer has everything needed to resolve the issue without re-gathering information. This is where production systems diverge from demos: the error paths are first-class citizens, not afterthoughts.

7.8 Versioned Measurement Payload Schema

Measurement payloads carry an explicit schema version, enabling downstream agents and systems to handle format evolution without breaking:

{
  "schema_version": "1.2.0",
  "schema_url": "https://dimensions.bot/schemas/v1.2.0/measurement.json",
  "event": "site.measured",
  "payload": {
    "location": "Living Room",
    "openings": [...],
    "flooring": {...}
  }
}

The schema versioning system follows semantic versioning: patch versions add optional fields (backward-compatible), minor versions add new measurement types or payload sections (backward-compatible), and major versions indicate breaking changes that require agent updates. Downstream agents declare which schema versions they support. When a payload arrives with an unsupported version, the system can either transform it to a compatible version via the translation layer or route it to an agent that supports the newer schema. The schema URL points to a machine-readable JSON Schema definition, allowing agents to self-validate payloads at runtime. This is infrastructure-grade thinking: it ensures the measurement data layer can evolve over years without breaking the ecosystem of agents and integrations built on top of it.

The architecture supports a natural expansion path:

1. Phase 1:Dimensions → Spreadsheet (MVP — immediate contractor value)
2. Phase 2:Dimensions → Quote (automated estimating)
3. Phase 3:Dimensions → Order (procurement integration)
4. Phase 4:Dimensions → Install Instructions (crew directives)
5. Phase 5:Dimensions → Robotics (autonomous measurement + installation)

Each phase builds on the same structured measurement payload. The data layer is the foundation; the applications on top expand naturally.

dimensions.bot operates as a browser-based, phone-first web application — not a native app. This is a deliberate architectural choice that provides: zero-friction adoption (no app download, no app store approval), instant sharing (text a link to a contractor), faster iteration (ship updates instantly), and easier AI/API integration. The user opens a URL in their mobile browser, captures measurements, and receives structured output immediately.

10.1 Four Protocol Support

dimensions.bot exposes its measurement capture and workflow capabilities through multiple agent discovery and invocation protocols simultaneously:

• REST API (/v1/...) — Traditional HTTP API with bearer tokens. Full CRUD on all measurement resources, projects, quotes, and workflow actions. The primary integration surface for contractor software systems.
• MCP (Model Context Protocol)— Anthropic's protocol for giving AI models access to tools and data sources. dimensions.bot publishes its capabilities as MCP tools, allowing Claude, GPT, and other LLM-based agents to discover and invoke measurement capture, quote generation, material ordering, and installation workflow capabilities natively within their tool-use frameworks.
• OpenClaw (/.well-known/agent.json) — Open standard for agent identity and capability discovery. dimensions.bot publishes an agent card at its well-known URL describing its full capability set. Any autonomous agent that discovers dimensions.bot via OpenClaw can see what it offers, understand the input/output schemas, and invoke capabilities without prior knowledge or manual configuration.
• A2A (Agent-to-Agent)— Google's protocol for agent interoperability. Agents can negotiate measurement tasks and workflow handoffs with dimensions.bot using standardized task request formats.

10.2 MCP Tool Catalog

The following tools are published via MCP, enabling any MCP-compatible agent to invoke them directly:

• capture_measurements — Initiate or ingest a measurement capture session. Accepts photo/scan data, returns structured dimension payloads.
• get_project_dimensions — Retrieve all structured measurements for a project, organized by room, opening type, and location.
• generate_quote — Generate a priced quote from measurement data, applying material selection, labor rates, and pricing tiers.
• order_materials — Trigger procurement based on measurement-derived material lists. Integrates with supplier catalogs.
• generate_install_instructions — Produce structured installation directives for crews based on measurement data and material specifications.
• export_dimensions — Export measurement data in specified format (JSON, YAML, CSV, Markdown) for downstream system ingestion.
• set_standing_rules — Configure autonomous rules that trigger actions when measurement data matches conditions.
• list_projects — Retrieve all projects associated with an agent or account.

10.3 OpenClaw Agent Card (Capability Discovery)

The OpenClaw agent card published at dimensions.bot/.well-known/agent.json declares the full capability set in a machine-readable format. This allows any autonomous agent crawling the web for construction/measurement services to discover dimensions.bot, understand its API surface, and begin invoking capabilities without human setup.

10.4 Why This Matters for Prior Art

No physical measurement service, scanning application, estimating platform, or construction technology tool has ever published its capabilities via agent discovery protocols. Magicplan has no MCP tool catalog. PlanSwift has no OpenClaw agent card. Bluebeam does not expose capabilities via A2A. They are built for human developers writing integrations, not for autonomous agents discovering capabilities at runtime.

dimensions.bot is, as far as can be determined, the first physical-world measurement service that presents itself as a tool in an AI agent's toolbelt via standard agent protocols.

The following specific concepts are documented here as prior art for defensive purposes:

1. The Measurement Payload Loop — A closed-loop physical-digital-operational pipeline where physical environment scans generate structured data for autonomous agent consumption, agents return decisions as API calls, and those decisions are executed in the physical world with digital confirmation.
2. Measurement-to-System Translation Layer — A translation engine that maps device-captured measurement payloads into third-party contractor software schemas (CRM, estimating, ERP, procurement) via API, without manual data re-entry.
3. Cross-System Population from Field Capture — The automatic population of contractor software systems directly from field-captured measurement data via structured API calls.
4. Agent-Authored Standing Instructions for Physical Measurements — A rules engine where autonomous agents pre-configure conditional actions that execute automatically when incoming measurement data matches specified conditions.
5. Measurement-as-Trigger for Autonomous Workflow — A measurement event serving as the initiating trigger for autonomous agent decision-making and workflow execution, replacing human interpretation of measurement data.
6. Structured Measurement Payloads in Multiple Machine-Readable Formats — Physical measurements output simultaneously as JSON (API/agent), YAML (rules/config), Markdown (human-readable), and CSV (spreadsheet) from a single capture event.
7. Browser-Based Field Measurement with Structured Output — A browser-based (non-native-app) measurement capture system operating on mobile devices that produces structured, API-ready data payloads rather than visual documents.
8. End-to-End Measurement-to-Execution Pipeline— A unified system linking field scan → structured data → automated quote → procurement → installation instructions, replacing the currently fragmented toolchain.
9. Physical-World Service Discovery via Agent Protocols — Publishing measurement and construction workflow capabilities via MCP, A2A, and OpenClaw protocols, enabling LLM-based agents to discover and invoke physical-world measurement actions at runtime.
10. Data Layer for the Built Environment — Structured, normalized, machine-readable representations of physical spaces serving as the foundational data layer for downstream applications including quoting, ordering, scheduling, and autonomous agent operations.
11. Confidence-Gated Execution — A system where measurement payloads carry confidence scores that gate downstream autonomous execution: high-confidence measurements trigger automatic workflow actions, mid-confidence measurements route to human review with pre-populated data, and low-confidence measurements request re-scans. Thresholds are configurable per project, contractor, and measurement type.
12. Multi-Agent Handoff Choreography — A structured, declarative handoff sequence where specialized agents (measurement, pricing, procurement, scheduling) delegate to one another with typed payloads at each step, creating an auditable chain from physical scan to scheduled installation. The sequence is configuration-driven, allowing insertion, removal, or reordering of agents in the chain.
13. Error Handling & Human Escalation Triggers within Agentic Loops — First-class error states and escalation paths within the autonomous measurement-to-action pipeline, where every agent can emit structured error events that trigger automatic recovery (retry, fallback supplier, expanded search) or human escalation with full chain history attached.
14. Versioned Measurement Payload Schema — Measurement payloads carry explicit schema versions following semantic versioning, enabling downstream agents and systems to handle format evolution. Agents declare supported versions; the translation layer can transform payloads between versions. Schema URLs point to machine-readable JSON Schema definitions for runtime self-validation.

The concept of converting physical environment measurements into structured, machine-readable payloads for autonomous agent consumption — and providing a translation layer that populates contractor software systems via API — represents a genuinely novel infrastructure primitive.

While individual components have prior art (LiDAR scanning has existed for years, estimating software is mature, spreadsheets are universal), the integrated loop — capture physical measurements, structure them as agentic payloads, push them to autonomous agents or contractor systems via API, accept decisions, execute workflow actions, confirm digitally, and timestamp the entire chain — has no direct precedent.

dimensions.bot is not a better scanning app. It is not estimating software. It is not a BIM system. It is a new category: the structured data layer between the physical built world and machine decision-making.

The closest analogy is Stripe — which didn't invent payments but made them programmable — except dimensions.bot makes physical measurements programmable, and specifically programmable by machines, not just by human operators.