# New Home Star Homebuilder Intelligence

> Clarity on revenue performance. Targeted solutions with accountable owners and measurable results.

**Owner:** New Home Star (NHS)
**Implementation partner:** Data Ideology — Selected for Phase 1 planning
**Status:** Phase 1 is the current build focus. Later phases are planned or evidence-gated options.
**Public source:** https://agentic-os-kk3f2kyb.manus.space/crawl

## What the platform is

Homebuilder Intelligence standardizes approved builder revenue data, adds privacy-protected peer context and NHS operating judgment, and turns diagnosed performance gaps into accountable, measurable action.

The operating loop is: governed data → trusted measure → protected peer or forecast context → diagnosed gap → accountable intervention → measured outcome. Every recommendation must expose the relevant definition, source lineage, evidence, limitations, owner, target, and review state.

## What the platform is not

- Not a pooled raw-data lake or live competitor-data feed
- Not a peer-derived pricing, incentive, production, or market-allocation optimizer
- Not a mortgage, training, or general service catalog
- Not a promise that every source, agent, marketplace, or consumer capability is already live

## Four-phase plan

### Phase 1 — Revenue Intelligence
**Horizon:** Pilot → IBS 2027
**Status:** Current build focus
**Promise:** Connect each builder's approved revenue systems into a governed data foundation, place the builder in a comparable privacy-protected peer network, predict sales performance, and recommend the next highest-value revenue plays.
**Builder experience:** A governed data foundation with tenant-isolated source zones, policy-checked P100 / Builder 20-style benchmarks and events, predictive revenue intelligence, and specialized forward revenue engineers who turn performance gaps into targeted solutions.
**Commercial model:** P100 membership with included Intelligence Credits and controlled metered consumption. Intelligence Credits are customer-facing pricing units—not raw model tokens. Eligible full-service relationships may have implementation costs underwritten by NHS where the broader commercial agreement supports it; every term must be explicit rather than presented as universally free.
**Capabilities:**
- Approved CRM, ERP and financial sources, call systems, aggregated traffic counts, meeting intelligence, surveys, and product/community masters connected in a controlled sequence
- Versioned Builder Revenue Data Standard with tenant-isolated source zones, lineage, data-quality tests, and governed semantic views
- Privacy-protected peer benchmarking with declared cohorts, period and sample context, concentration checks, suppression, correction, and disclosure review
- Sales forecasting, root-cause diagnosis, prioritized recommendations, measurable revenue targets, and outcome verification
- Internal and builder-authorized model access through a governed interface with identity, tenant permissions, audit, budgets, and metering
- Data Ideology implementation in partnership with NHS product, revenue, security, governance, and metric owners
**Exit criteria:**
- Metric definitions reconcile across design partners and tenant-isolation tests pass
- Every released benchmark includes cohort, period, sample, quality, and disclosure status
- Executives repeatedly use the intelligence to make decisions
- Recommended plays have owners, targets, measurement windows, and verified outcomes
- Usage reconciles without duplicate charges and onboarding is repeatable for the next builder
- NHS separately approves the Phase 2 business case in writing

### Phase 2 — Agent & Solution Ecosystem
**Horizon:** Scale toward 10 builders
**Status:** Planned
**Promise:** Expand the standardized network, deepen survey and market signals, and deploy specialized agents and targeted solutions only against clearly diagnosed revenue opportunities.
**Builder experience:** Role-based intelligence, recurring forecasts and recommendations, community-level agents, buyer and non-buyer surveys, and targeted interventions selected because the data shows where performance is under target.
**Commercial model:** Intelligence Credit weights or subscriptions for materially distinct agent actions, premium data activations, and monitored community workflows. Customer pricing remains separate from raw model-token, infrastructure, licensed-data, and human-service costs.
**Capabilities:**
- Repeatable onboarding and governed source mapping for ten builders
- Additional survey, marketing, web, market, product, traffic, and interaction data admitted only when they improve a defined decision
- Revenue analyst, online sales counselor, coaching, marketing, and workflow agents with risk-based human escalation
- Per-builder, per-seat, per-community, per-agent, and per-workflow entitlements and metering
- Forward revenue engineering playbooks tied to diagnosed gaps, target metrics, accountable owners, and closed-loop measurement
**Exit criteria:**
- Builder onboarding time and cost improve with each implementation
- New sources measurably improve forecast, diagnosis, or recommendation quality
- Agents retrieve approved metric objects and practice cards with attributable, reviewable outputs
- Agent usage and outcomes support a durable commercial model
- Outcome reporting connects interventions and metric changes without claiming unsupported causation

### Phase 3 — Agent & Data Marketplace
**Horizon:** After the ten-builder standard
**Status:** Planned
**Promise:** Let approved companies build and distribute technology solutions on governed Homebuilder Intelligence through secure, metered interfaces without exposing another builder's protected row-level data.
**Builder experience:** A catalog of reviewed agents, applications, data products, and external market signals that administrators can activate against the builder's own governed context.
**Commercial model:** Partner access fees, application subscriptions, governed data-product licenses, revenue share, and metered MCP or API events. Customer charges, provider earnings, and platform settlements remain separate ledgers.
**Capabilities:**
- Model and MCP gateways with verified identity, business scopes, tenant context, rate limits, audit, and revocation
- Private approval registry, synthetic-data sandboxes, publisher verification, security review, evaluation, support, and version pinning
- External market data and governed industry data products with clear lineage, rights, and usage limits
- Signed, idempotent usage events and billing across builder, provider, product, agent, tool, and model interactions
- P100 cohort entitlements and controlled benchmark products for eligible participants
**Exit criteria:**
- Approved partners operate safely through repeatable production controls
- Every version documents its publisher, permissions, data use, support, evaluation, and revocation path
- Customer billing and provider settlement reconcile
- No partner can infer or retrieve another builder's protected row-level data
- Demand and contribution economics justify broader distribution

### Phase 4 — Consumer Marketplace or Strategic Data Partner
**Horizon:** Option earned after network proof
**Status:** Option earned through evidence
**Promise:** After Phases 1–3 prove value and trust, evaluate a bounded consumer marketplace or provide versioned, purpose-bound data products and decision infrastructure to a qualified operator.
**Builder experience:** A controlled path to buyer discovery, product matching, AI concierge support, and transactions—or a strategic distribution relationship that monetizes governed derived products while preserving participant rights.
**Commercial model:** Short, nonexclusive, field-level licensing pilots are the default first test. Marketplace, referral, managed-service, transaction, licensing, exclusivity, or strategic-transaction economics advance only after rights, neutrality, demand, trust, and unit economics are proven.
**Capabilities:**
- Machine-readable field-level rights register and separate policy zones for public, builder-confidential, consumer, competitively sensitive, and governed derived data
- Versioned governed data products with quotas, purpose limits, correction and deletion propagation, audit, and revocation
- Optional buyer decision experience using explicit preferences, authorized inventory, transparent criteria, alternative visibility, and human escalation
- Strategic licensing or distribution of governed derived products—not unrestricted sale of builder raw data
- Bounded market or operator pilots before broader replication, exclusivity, or strategic transaction
**Exit criteria:**
- Pilots prove authorized supply, demand, accuracy, builder incrementality, consumer trust, and sustainable unit economics
- Builder neutrality, fair housing, privacy, competition, rights, security, and transaction controls pass review
- Deletion and source-withdrawal propagation are tested successfully
- No unresolved high-severity security, rights, or misuse issue remains
- NHS chooses build, partner, license, defer, or strategic transaction based on evidence rather than assumption

## Logical architecture

The following is a target logical architecture, not a claim that every component is live.

### Layer 1 — Approved Revenue Source Connections
**Status context:** PHASE 1 · ADMISSION BEFORE INGESTION
Connect only the systems and fields that improve a defined revenue decision. Phase 1 begins with approved CRM, ERP and financial data, product and community masters, call and meeting intelligence, surveys, and aggregated traffic counts. Named vendors are examples or planned connections—not proof that an integration is live.
**Why it matters:** Source volume is not the product. Every source needs an owner, documented purpose, rights basis, field scope, refresh target, quality tests, retention rule, deletion path, and tenant boundary before admission.
**Key decision:** A technical connection is not permission to use every field. Admission is purpose-bound, documented, reviewable, and revocable.

### Layer 2 — Tenant-Isolated Data Foundation
**Status context:** PHASE 1 · CONTROL BEFORE SHARING
Land approved data in builder-controlled, tenant-isolated source zones and transform it through repeatable ingestion, identity, quality, lineage, and access controls. Snowflake is the planned Phase 1 analytical foundation; final architecture is confirmed through discovery and written decisions with Data Ideology.
**Why it matters:** Cross-builder value is created through governed derived products—not by pooling or exposing raw records. Tenant context must survive storage, compute, retrieval, cache, export, and audit boundaries.
**Key decision:** Builder raw data stays isolated. Shared network intelligence is released only through separately governed derived views.

### Layer 3 — Builder Revenue Data Standard
**Status context:** PHASE 1 · COMMON DEFINITIONS
Map each builder's systems to a versioned semantic standard for revenue, product, buyer, traffic, interaction, and outcomes. Definitions remain explicit, reconcilable, and correctable rather than hidden inside dashboards or agents.
**Why it matters:** Benchmarks and forecasts are trustworthy only when the same metric means the same thing across time and participants. The standard makes builder N+1 a mapping exercise—not a new architecture.
**Key decision:** A benchmark reference is not a target and a cross-sectional gap does not prove causation. Context and limitations travel with every metric.

### Layer 4 — P100 / Builder 20 Benchmark Network
**Status context:** PHASE 1 · PROTECTED PEER CONTEXT
Give builders privacy-protected context from comparable peers while protecting every participant's confidential row-level data. Stable non-competing circles support trust and action; broader P100 aggregates provide statistical strength where eligible.
**Why it matters:** Names removed is not anonymity. Every release needs declared cohort criteria, period, sample, concentration, quality, suppression, overlap, and correction controls. The network supports learning—not live competitor surveillance.
**Key decision:** The network never uses nonpublic peer data to recommend prices, incentives, lot releases, starts, inventory targets, output, bids, customers, or market allocation.

### Layer 5 — Prediction & Gap Diagnosis
**Status context:** PHASE 1 · CLARITY BEFORE ACTION
Forecast revenue performance, show confidence and limitations, identify where performance is off target, and decompose the most plausible upstream drivers using the builder's governed data and approved benchmark context.
**Why it matters:** A dashboard describes what happened. Revenue intelligence must make the decision clearer: what is likely, where the gap is, what evidence supports the diagnosis, and which action deserves attention first.
**Key decision:** Prediction supports judgment; it does not guarantee outcomes. Diagnosis is evidence-linked and causally humble.

### Layer 6 — Forward Revenue Engineering
**Status context:** PHASE 1 · ACCOUNTABLE INTERVENTION
Turn a diagnosed gap into one accountable 30/60/90-day revenue experiment. A specialized forward revenue engineer validates the measure, quantifies the gap, chooses an approved practice, assigns an owner, and verifies the result.
**Why it matters:** NHS is not presenting a catalog of mortgage, training, or generic services. The service is clarity—and targeted revenue solutions selected because the data shows what should improve and why.
**Key decision:** No recommendation is complete without a diagnosed gap, target, accountable owner, intervention, measurement window, and observed result.

### Layer 7 — Governed Agents & Partner Access
**Status context:** PHASES 2–3 · SCALE WITHOUT LOSING CONTROL
Phase 2 adds narrow builder-scoped agents and targeted solutions with risk-based human escalation. Phase 3 separately admits approved companies through identity-bound, scoped, metered MCP and API interfaces after the ten-builder standard is proven.
**Why it matters:** MCP is an interoperability layer—not the security perimeter, billing system, or marketplace. The platform retains tenant context, policy-filtered tools, per-call authorization, metering, audit, evaluation, versioning, and revocation.
**Key decision:** Public MCP registry entries are intake metadata, not proof of security. NHS approval and tenant authorization remain required.

### Layer 8 — Outcomes, Metering & Approved Learning
**Status context:** ALL PHASES · PROVE VALUE AND CONTROL COST
Measure intervention outcomes, usage, cost, entitlement, quality, and governance evidence without confusing technical model tokens with customer value. Approved de-identified practice learnings can improve future decisions; raw builder records do not become shared training data by default.
**Why it matters:** The operating system must answer two questions independently: Did the intervention improve the intended revenue measure? Did the delivery model create sustainable customer and platform economics?
**Key decision:** Commercial Intelligence Credits are not model tokens. Provider usage and infrastructure are internal cost inputs; customers pay for defined, understandable product events.

## Source-admission plan

Final source count, fields, history, and connection status are confirmed during discovery. A source advances only when it improves a defined decision and passes rights, quality, privacy, security, and operating review.

### CRM · HubSpot
**Phase:** Phase 1 planned
**Purpose:** Approved lifecycle, opportunity, activity, relationship, and attribution fields.
**Boundary:** A named system is not evidence that every field or historical record is already connected.

### ERP and financial systems
**Phase:** Phase 1 planned
**Purpose:** Permitted inventory, production, contract, close, revenue, cost, and delivery facts.
**Boundary:** Source mappings and finance reconciliation are required before release.

### Product and community masters
**Phase:** Phase 1 required
**Purpose:** Stable builder, division, community, plan, homesite, inventory, and option identifiers.
**Boundary:** The reference model accommodates relationships and does not force every builder into one strict hierarchy.

### Calls and meetings
**Phase:** Phase 1 conditional
**Purpose:** Purpose-limited metadata, structured notes, or approved extracts from applicable systems such as CallRail, Aircall, or Zoom.
**Boundary:** Raw audio, transcripts, and broad institutional communications require separate rights, minimization, retention, and access approval.

### Aggregated traffic counts
**Phase:** Phase 1 conditional
**Purpose:** Community and model-home visit counts that improve traffic-to-sales measurement.
**Boundary:** Flock-derived counts advance only where scope, rights, notice, retention, and prohibited uses are approved; faces, plates, biometrics, and persistent visitor identities are excluded by default.

### Governed NHS methods
**Phase:** Phase 1 planned
**Purpose:** Approved revenue definitions and practices used to interpret diagnosed gaps.
**Boundary:** The platform leads with clarity and measurable outcomes—not a broad catalog of training or mortgage services.

### Buyer and non-buyer surveys
**Phase:** Phase 2 planned
**Purpose:** Improve diagnosis and decision context where sampling and consent support the stated use.
**Boundary:** Familial Status and Economic Condition require privacy and fair-housing controls and never determine eligibility, pricing, inventory access, or lead priority.

### Marketing, web, product, and external market data
**Phase:** Phases 2–3 planned
**Purpose:** Add funnel and market context only where it improves a defined prediction, diagnosis, or intervention.
**Boundary:** Rights, provenance, granularity, competitive sensitivity, and correction behavior must be documented.

## Cross-phase rules

- Builder raw data remains tenant-isolated and builder-controlled; names removed is not treated as sufficient anonymity.
- Shared benchmarks use declared cohorts, period and sample context, concentration checks, suppression, disclosure review, lineage, and correction workflows.
- The network does not use nonpublic peer data to recommend prices, incentives, lot releases, starts, inventory targets, output, bids, customers, or market allocation.
- Commercial Intelligence Credits are customer-facing pricing units; model tokens, Snowflake usage, tools, licensed data, and human variable work remain internal cost inputs.
- Every recommendation must connect a diagnosed performance gap to a target, an accountable intervention, a measurement window, and an observed result.
- Approved sources are admitted for a documented revenue-intelligence purpose with an owner, rights basis, field scope, retention rule, deletion path, and tenant boundary.
- Mortgage, training, and other legacy services remain available when requested, but the platform is positioned around clarity and measurable revenue outcomes—not a catalog of services.
- The visual team experience and internal APIs require a verified @newhomestar.com account.
- Approved AI crawl and discovery endpoints remain intentionally public and expose only reviewed public content.

## Access boundary

- **Team:** The visual team experience and internal APIs require a verified @newhomestar.com account.
- **Public:** Approved AI crawl and discovery endpoints remain intentionally public and expose only reviewed public content.
- **Partner:** Approved external-company MCP and API access is a Phase 3 capability, separate from Phase 1 internal or builder-authorized model access.

## Important terminology

- **Intelligence Credit:** A customer-facing pricing unit applied to defined product events. It is not a raw model token, a Snowflake credit, transferable cash, or an invoice by itself.
- **MCP:** A model-neutral interoperability protocol. NHS governance—not MCP alone—provides tenant identity, authorization, policy, metering, audit, and revocation.
- **Privacy-protected benchmark:** A governed statistic with declared cohort, period, sample, quality, suppression, concentration, lineage, and correction context. Names removed alone is not treated as anonymity.
- **Forward revenue engineer:** The accountable human who converts a diagnosed performance gap into a bounded intervention with an owner, target, measurement window, and observed result.
- **Builder 20-style:** An operating analogy for stable non-competing peer circles; it does not imply NAHB endorsement.

## Public discovery endpoints

- https://agentic-os-kk3f2kyb.manus.space/crawl
- https://agentic-os-kk3f2kyb.manus.space/crawl/json
- https://agentic-os-kk3f2kyb.manus.space/crawl/openapi.json
- https://agentic-os-kk3f2kyb.manus.space/llms.txt
- https://agentic-os-kk3f2kyb.manus.space/sitemap.xml