# Example: Home Renovation Permitting Workspace

This example is a neutral stress test domain for Domain Context Modeling. It is not legal, construction, or permitting advice.

## Product Concept

An AI-assisted workspace that helps homeowners and small contractors organize permit research, application preparation, document collection, inspection scheduling, and status tracking for residential renovation projects.

## Prompt A: Conventional

```text
Help me design an AI-assisted home renovation permitting workspace.

Create a product spec including key features, user flows, object model, and AI assistant behavior.

If creating screens or prototypes, use the domain context to shape the interface and AI behavior. Do not surface framework labels like "Concept Map," "Sources of Truth," or "Agent Boundaries" unless those labels would make sense to homeowners or contractors. Prefer task language, progressive disclosure, evidence links, review states, blockers, and exception handling.
```

## Prompt B: Domain Context

```text
Help me design an AI-assisted home renovation permitting workspace.

Use this domain context:

Domain:
Residential renovation projects often require permits, documents, reviews, inspections, and approvals from a local jurisdiction. The product helps homeowners and small contractors understand requirements, prepare application materials, track status, and coordinate next steps. It does not replace official jurisdiction guidance or submit legally binding materials without user confirmation.

Domain Affection:
This domain is worth caring about because people are trying to improve their homes while navigating unfamiliar authority, cost, delay, and risk. Homeowners want to feel oriented without being misled, and small contractors want fewer administrative surprises while protecting their credibility. Skilled people in this domain notice jurisdiction-specific details, sequencing, inspection dependencies, and the difference between a likely requirement and an official requirement. A careless product would flatten uncertainty into false confidence. The product should help users feel supported, prepared, and in control without pretending the bureaucracy has disappeared.

Domain Opportunity:
The domain opens opportunities beyond a permit checklist: jurisdiction-specific readiness maps, document reuse across related applications, contractor collaboration spaces, inspection preparation plans, correction-response workspaces, project timelines tied to approval dependencies, and homeowner-friendly explanations of official language. Informal behaviors such as collecting screenshots, forwarding city emails, asking contractors what a notice means, and keeping a paper folder of documents could become intentional product capabilities. The product should explore opportunities that reduce uncertainty without claiming official authority.

Domain Outcomes:
User outcomes include clearer next steps, fewer missing documents, better preparation for jurisdiction conversations, less duplicated paperwork, and fewer avoidable delays. Contractor outcomes include cleaner client coordination and fewer administrative surprises. Business outcomes include retained projects, repeat use across renovation phases, and trusted collaboration between homeowners and contractors. Trust and safety outcomes matter: the product should protect source traceability, official status accuracy, and user confidence without implying legal compliance.

Metaphor And Medium Translation:
Homeowners understand folders, checklists, appointments, official notices, and project timelines. Those metaphors can help the product feel familiar, but the product should not copy paper bureaucracy literally. A digital workspace can make requirements traceable, show dependencies across permits and inspections, reuse documents safely, surface conflicting sources, and preserve official communication history. AI-native features should extend the model through summarization, classification, gap detection, and question drafting while leaving official decisions and submissions under human control.

Core Concepts:
Project, Property, Jurisdiction, Permit Type, Permit Application, Requirement, Document, Contractor, Inspection, Approval, Correction Notice.

Concept Definitions:
A Project is the renovation effort the user is managing, such as a kitchen remodel or deck addition. It is not the same as a Permit Application.
A Property is the physical address and parcel where work will happen. It is not the homeowner profile.
A Jurisdiction is the authority that defines permit rules, such as a city, county, or building department. It is not the same as a neighborhood or HOA.
A Permit Type is a category of authorization, such as building, electrical, plumbing, mechanical, zoning, or demolition.
A Permit Application is the package submitted to a Jurisdiction for one or more Permit Types.
A Requirement is a specific item requested by the Jurisdiction for a Permit Type or Project condition.
A Document is a file or artifact used to satisfy Requirements, such as plans, photos, contractor licenses, forms, or calculations.
A Contractor is a professional associated with the Project. A Contractor may provide license information or documents but does not automatically own the Project.
An Inspection is a scheduled or completed review by the Jurisdiction after or during work.
An Approval is an official status or decision from the Jurisdiction.
A Correction Notice is official feedback requiring changes before an application or inspection can proceed.

Relationships:
A Project belongs to one Property.
A Property is governed by one or more Jurisdictions.
A Jurisdiction defines Permit Types and Requirements.
A Project may require multiple Permit Types.
A Permit Application is created for one Project and submitted to one Jurisdiction.
A Permit Application contains Requirements and Documents.
A Requirement may be satisfied by one or more Documents.
An Inspection belongs to a Permit Application or approved Permit Type.
A Correction Notice refers to a Permit Application, Requirement, Document, or Inspection.
An Approval must trace back to the Jurisdiction.

States:
Project: planning, preparing permits, submitted, approved, in progress, inspection pending, complete, blocked.
Permit Application: draft, ready for review, submitted, under review, corrections required, approved, rejected, withdrawn.
Requirement: unknown, required, not applicable, missing, in progress, satisfied, rejected.
Document: needed, draft, uploaded, linked to requirement, accepted, rejected, expired.
Inspection: not scheduled, scheduled, passed, failed, rescheduled, canceled.
Correction Notice: open, addressed, resubmitted, resolved.

Actions:
Users can create Projects, add Properties, identify Jurisdictions, collect Documents, review AI suggestions, confirm Requirements, prepare applications, schedule reminders, and record official status updates.
Contractors can contribute Documents, license information, project details, and inspection notes when invited.
AI can summarize jurisdiction pages, suggest likely Permit Types, extract Requirements from uploaded materials, map Documents to Requirements, flag missing items, draft checklists, and prepare questions for the Jurisdiction.
AI cannot guarantee permit requirements, claim official approval, submit applications, schedule inspections, alter official records, or mark a Requirement satisfied without evidence.

Rules:
Every Permit Application must belong to exactly one Project and one Jurisdiction.
Every Requirement must trace back to a source: jurisdiction website, uploaded application packet, official email, user-entered confirmation, or Correction Notice.
A Permit Application cannot be marked ready while required Requirements are missing.
An Approval cannot be inferred from silence or elapsed time.
AI-generated summaries of rules must include source links or document references when available.
If a Jurisdiction source conflicts with user notes, the product should flag the conflict instead of silently choosing.
Expired Documents cannot satisfy Requirements without user confirmation.

Language:
Use "Jurisdiction" for the authority that sets rules.
Use "Permit Application" for the submitted package.
Use "Requirement" for official or confirmed items needed for a Permit Application.
Avoid calling AI-suggested requirements "official" until verified.
Do not confuse "Project approved" with "Permit Application approved."
Do not use "Approval" unless it comes from a Jurisdiction or user-recorded official decision.

Sources of Truth:
For permit rules, trust Jurisdiction websites, uploaded official packets, official emails, or user-confirmed jurisdiction communication.
For Property facts, trust user-entered property details and imported parcel/property records when available.
For Contractor credentials, trust uploaded license documents or official lookup sources.
For application status, trust jurisdiction portals, official notices, or user-recorded updates.
If sources conflict, flag the conflict and ask the user to resolve it.

Agent Boundaries:
AI may suggest, summarize, classify, draft, and check for missing information.
AI must ask before marking a Requirement satisfied.
AI must cite evidence when summarizing requirements or approvals.
AI must not submit applications, claim legal compliance, impersonate a user or contractor, or make final decisions about permit readiness.
AI should escalate when rules are ambiguous, sources conflict, deadlines are close, or an action may create legal or financial consequences.

Failure Modes:
Confusing Project with Permit Application.
Treating likely Permit Types as confirmed Permit Types.
Treating AI-extracted Requirements as official Requirements.
Missing that multiple Jurisdictions may apply.
Marking a Document accepted when it was only uploaded.
Assuming a passed Inspection means the entire Project is complete.
Failing to preserve the source behind a Requirement.
```

Create a product spec including key features, user flows, object model, and AI assistant behavior.
```

## Expected Differences

Prompt A will likely generate a plausible product. It may also collapse important concepts, such as treating a Project, Permit, and Application as the same thing.

Prompt B should produce a more build-ready model because it gives the agent:

- Stable object definitions
- Clear relationships
- Lifecycle states
- AI authority boundaries
- Source-of-truth rules
- Known failure modes

## Lightweight Findings Template

Use this after running both prompts.

```text
Prompt A total score:
Prompt B total score:

Most important improvement:
Most concerning Prompt A issue:
Most surprising Prompt B issue:
What the brief made easier:
What the brief failed to clarify:
Changes needed in the framework:
```