> For the complete documentation index, see [llms.txt](https://docs.buzzy.buzz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buzzy.buzz/the-building-blocks/mcp/buzzy-builder-mcp/adapt-sitepulse.md).

# Adapt SitePulse for operations

Use SitePulse’s location → signal → alert → response pattern as the starting point for a separate facilities app. This guide supplies a proposed brief and acceptance checks; it does not claim the facilities adaptation has already been built.

{% embed url="<https://www.youtube.com/watch?v=jz8eAaElxnc>" %}
Watch the template overview
{% endembed %}

## Before you begin

Follow [Getting started with Builder MCP](/the-building-blocks/mcp/buzzy-builder-mcp/getting-started.md). Preview [SitePulse Operations Dashboard – Native](https://app.buzzy.buzz/app/40f133f5262c757cfa69db41).

The recorded example mixes operational sample records with external feeds. Dates and status labels in a demonstration are not a verified assessment of a site. For your target, define the site inventory, source owners, operator roles and one response workflow.

## 1. Ask the agent to inspect the source

```
Bootstrap this repository with Buzzy Builder MCP and read its current guides.
Inspect SitePulse Operations Dashboard – Native, app 40f133f5262c757cfa69db41:
https://app.buzzy.buzz/editor/edit/40f133f5262c757cfa69db41
Preserve the source. Identify locations, external feeds, sample operational
records, alerts, tasks, permissions and navigation. Explain which information
is live, manually entered, derived or demonstration data. Report uncertainty.
Do not change any app yet.
```

Review the actual source and bindings. A healthy-looking integration row is not sufficient evidence that a feed is configured and working.

## 2. Define one facilities response journey

Use a bounded initial path: an operator reviews an issue at a site, assigns a task, records progress and confirms completion.

Specify who may create, assign and close work. Decide whether closing a task also resolves an alert, whether completion needs evidence, and what should happen when the same issue is reported twice.

For each signal, document its source, units, timestamp meaning, acceptable age and failure behaviour. Keep observed conditions separate from recommendations and confirmed decisions.

## 3. Plan a separate target app

```
Plan a separate facilities operations app using the inspected SitePulse pattern.
Never edit the source. Start with one site and one issue-to-response workflow.
Use our agreed roles, task lifecycle, signal definitions and freshness policy.
Map keep/remove/replace/add decisions across data, screens and workflows.
Identify external-service configuration and any separately billed work.
Show the target plan and review stages before implementation.
```

Record the target app ID and editor URL. Follow the current Builder MCP guide’s staged workflow. Review the target data model and permissions before wiring screens or connecting real sources.

## 4. Make freshness and ownership visible

Ask the agent to make the source and timestamp understandable beside a signal. A stale or failed source should have an explicit state. Agree what the operator can do next rather than defaulting missing information to “normal”.

Show the site context on an alert and its response task. Keep task ownership and lifecycle changes visible. Use synthetic events to exercise the workflow before enabling operational actions.

## 5. Test the complete path

| Scenario               | Expected behaviour to agree and verify                                |
| ---------------------- | --------------------------------------------------------------------- |
| Fresh reading          | Correct units, source and timestamp are shown                         |
| Stale reading          | Staleness is visible under the agreed policy                          |
| Missing or failed feed | A distinct unavailable state appears                                  |
| Duplicate event        | Handling follows the agreed duplicate policy                          |
| Task assignment        | Correct site/alert context and authorised owner are retained          |
| Completion             | Required information is present and related state changes are correct |
| Restricted user        | Other sites’ protected records and actions remain inaccessible        |
| Mobile or keyboard use | Main review and response controls remain usable                       |

Record the target build, scenarios, expected and observed results, role and screenshots. Validate thresholds with the business owner; the demo’s labels do not establish the target’s operating policy.

## Troubleshooting

For an unexpected alert, inspect its source, unit conversion, timestamp and threshold before changing the rule. If a task appears at the wrong site, inspect the relationship IDs in the saved target records. If a source is unavailable, surface that failure rather than substituting an unexplained value.

## Cost and rollout

Direct artifact edits can use the connected agent’s eligible allowance without Buzzy generation credits. External services may have their own costs or terms; API usage, Buzzy generation and deployment are separate. See [AI usage and pricing](https://docs.buzzy.buzz/working-with-buzzy/buzzy-ai/ai-tokens-and-pricing).

Expand beyond the first site after the agreed scenarios pass. Follow the [deployment publishing guide](https://docs.buzzy.buzz/working-with-buzzy/buzzy-deployment-and-app-stores/publish-to-deployment) and repeat the relevant checks in the deployed target.

## Explore the template series

Read the [article overview](https://www.buzzy.buzz/post/sitepulse-operations-builder-mcp/) or explore the [complete Builder MCP template series](https://www.buzzy.buzz/post/build-from-templates-builder-mcp/).