# Describe installed technology without promising compatibility.

A smart-home specification page describes documented hardware, preparation and demonstrated functions separately from services and buyer accounts. Give each statement a project scope and an evidence source. Keep compatibility, security and future support claims unpublished until the applicable evidence supports them. A photograph alone does not establish a working integration.

## What hardware is documented?

Start with the device category and the applicable project record. Avoid beginning with a promise that the house is connected. That phrase leaves the reader to decide what connects, who supplies it and what remains to be arranged.

Use your [standard specifications page](/articles/builder-websites/standard-specs-page/) for the broader inclusion labels. This technology page adds a separate record for hardware, preparation, demonstrated functions, service dependencies and account responsibility. It does not replace the approved project specification.

Separate three statements that a draft might combine. The specification calls for a device. A field record confirms installation. A reviewed demonstration record describes a function observed under stated conditions. Publish only the statement your current evidence supports.

For example, a specified wall control is not automatically an installed wall control. An installed wall control does not establish remote access. A recorded local demonstration does not establish compatibility with the buyer's devices. Keep each claim within its own evidence boundary.

| Public statement | Record to check | Question left separate |
| --- | --- | --- |
| Specified hardware | Applicable approved specification | Has installation been confirmed? |
| Installed hardware | Reviewed installation record | Which functions have been demonstrated? |
| Preparation only | Approved preparation scope | Which devices remain outside that scope? |
| Demonstrated function | Reviewed demonstration note and conditions | Does the proposed public wording exceed the observation? |
| Separate service | Applicable service information | Who confirms enrollment and current terms? |

Give a reviewer enough information to find the source without publishing the private source itself. Keep equipment access details, account identifiers and household information outside the website draft. Your public reader needs the scope boundary, not access to the equipment.

Set the scope at the smallest useful level. One documented device in one completed project supports that project description. It does not establish an inclusion across every plan, community or future build. Put any broader standard through its own specification review.

## What is only preparation?

Give preparation its own label wherever it appears. If the approved record describes prewiring, use that description. Do not convert it into an installed system because a rendering shows a screen or the room looks ready for equipment.

Ask the responsible project reviewer what the preparation record establishes. Request an approved public sentence about that scope. Leave the eventual device, service and demonstrated function unresolved when the record does not address them. Do not fill those gaps with a generic technology package description.

Use the same boundary in image captions. A wall location in a photograph may help orient the buyer, but the caption should not claim an unseen connection. The [project gallery guide](/articles/builder-websites/project-gallery-pages-that-sell/) explains how to connect a photographed feature to its documented project decision.

For informative images, write text alternatives around the information the image contributes in context. W3C explains this approach in its [informative images tutorial, Overview and Example 2](https://www.w3.org/WAI/tutorials/images/informative/). That guidance concerns image presentation. It does not verify equipment scope or performance.

Keep labels close to the feature they describe. A caption such as “Preparation shown; installed device scope remains unconfirmed” is an editorial example. Use it only when the approved project record supports the preparation statement. Do not apply the sentence to an unidentified photograph.

### How do you prepare a copyable technology scope register?

Copy the fields below into your internal review document. This register is an editorial proposal, not a prescribed technical inspection. Use one row per component category and scope state. Split a row whenever its service or account responsibility differs.

```
Technology scope register
Component category:
Installed or prepared state:
Evidence:
Service dependency:
Account responsibility:
Open claim:
Public sentence:
```

In the evidence field, record the source title, revision and approving role. In the open claim field, write the exact question that prevents stronger wording. “Compatibility unknown” is more useful than a blank box that another writer might treat as permission.

Keep a private review status beside the worksheet. A completed public sentence is still a draft until its responsible reviewer confirms the wording. Preserve an explicit unknown when confirmation does not arrive. Omit the feature if even its basic scope cannot be established.

## Which services are separate?

Ask a separate service question for every documented device category. Does the proposed function depend on enrollment, an account or another service? An unknown dependency remains unknown. Do not assume an installed device includes an active service, or that the buyer must enroll.

Separate service information from hardware inclusion. Keep provider names, prices and unverified terms out of the public summary. Where your approved records establish a later enrollment step, explain that step at the level the project reviewer confirms.

For a service question still under review, use an internal note such as “Enrollment responsibility requires confirmation.” Do not turn that note into public instructions to open an account. The responsible party must first establish which service information applies to the selected equipment and project.

1. Collect the current specification and the applicable installation evidence.

2. Separate installed hardware from preparation and proposed equipment.

3. List each function you intend to describe.

4. Attach evidence for that function and its stated conditions.

5. Ask the responsible reviewer to confirm service dependencies and account responsibility.

6. Remove claims that remain unsupported.

7. Approve the public sentence against the source revision.

Use this process before transferring copy into the [Owned website stage](/process/owned-website/). Keep the review record with the source material. Publishing access does not give an editor authority to resolve product questions.

If a source changes, return to the affected sentence. Do not silently preserve an older service description beside newly selected hardware. Record whether the old sentence was removed, narrowed or confirmed again. Keep the public page aligned with the applicable project scope.

## Who controls the accounts?

Record the responsibility question without exposing the account. Identify which role confirms account creation, enrollment and [handoff](/process/handoff/). If the buyer is responsible, establish that from the approved record before saying so. If responsibility is unresolved, leave it unresolved in the worksheet.

Keep account responsibility distinct from hardware supply and demonstration. One role may approve the specification while another handles orientation. Neither fact establishes who owns a future account. Request confirmation rather than deriving ownership from who attended a walkthrough.

Do not publish account names, access codes, pairing details or images of private settings. Review screen captures before selecting them for the page. A photograph can be unnecessary when a short approved sentence explains the inclusion boundary more clearly.

### What does a fictional review look like?

Consider a fictional, unnamed project used only to demonstrate the worksheet. Its invented review folder contains an approved wall-control installation record and a separate preparation note. No service terms or account assignment are supplied. No actual project, product or capability is represented.

The first row reads: component category, wall control; state, installed; evidence, fictional approved installation record. Service dependency and account responsibility remain unknown. The open claim asks whether remote operation is supported. The proposed public sentence describes installation only.

The second row reads: component category, future equipment connection; state, preparation only; evidence, fictional approved preparation note. The eventual device and service remain unknown. The public sentence describes preparation without claiming that a working system is included.

Fictional public excerpt: This project record confirms an installed wall control and separate preparation for future equipment. Preparation does not describe installed equipment. Service enrollment, account responsibility and remote operation remain unconfirmed in this example.

The reviewer leaves remote operation out of the approved claim set. A request for stronger language returns to the source owner. It does not go to the photographer or copy editor for an inference from the image.

## What claims stay unpublished?

Hold security, privacy, compatibility, subscription terms, reliability and future support claims when applicable primary evidence has not been reviewed. Avoid umbrella phrases such as “works with everything” or “ready for any future system.” Replacing them with another broad adjective leaves the evidence problem unresolved.

The FTC states that advertising must be truthful and non-misleading in its [Truth In Advertising guidance](https://www.ftc.gov/news-events/topics/truth-advertising). That principle supports checking public claims. It does not approve this worksheet or establish a technology feature in your home.

Keep a proposed sentence beside its evidence during final review. Ask what a buyer could reasonably take that sentence to include. If the sentence joins documented hardware with an undocumented service, separate those ideas before approval. Retain the unresolved question in the private register.

Coordinate this page with your [custom builder website page set](/guides/custom-builder-website-pages/). The project page, specification summary and inquiry response should use the same scope labels. Review repeated copy when a source revision changes a claim.

For equipment in a kitchen or utility space, use the [appliance package sheet](/articles/builder-websites/appliance-specification-page-content/) to record supply and selection separately. The [builder website article collection](/articles/builder-websites/) connects these narrower records to the broader public content.

## What else should you ask about smart-home specification pages?

### Can a photograph establish that devices work together?

A smart-home photograph does not establish compatibility. Describe the documented visible feature and its scope. Hold integration claims until applicable evidence supports the exact function you intend to publish.

### Should preparation appear in the installed device list?

Smart-home preparation should have a separate scope label. Describe only the preparation supported by the approved record. Leave eventual equipment, services and operating functions unresolved when the record does not confirm them.

### Where should buyer account questions go?

Record smart-home account responsibility in the private technology scope register. Ask the responsible project role to confirm it. Publish only an approved responsibility statement, without account identifiers or access details.

### Does one project's technology become a standard inclusion?

A documented smart-home feature in one project does not establish a builder-wide standard. Check any broader inclusion statement against the current applicable specification before using it on other project or plan pages.