What Heartwood draws on, and what it doesn't claim to know

Why this page exists

A buyer, an auditor, or an AI agent acting on a buyer's behalf needs to know what data Heartwood draws on and what it explicitly does not claim to know, in detail, at a clean URL. The methodology page covers how a brief is made: the prompt scoring, the seven-section format, the two-pass review. This page covers what's underneath: the inputs, the boundaries, and the explicit gaps.

Both pages are public on purpose. If you're going to act on a Heartwood Decision Brief, you should be able to read its sources and its limits the same way you'd read a financial model's assumptions before deciding whether to trust the number at the bottom.

Data sources we use

Every Heartwood brief is built from a small, named set of inputs. We don't pretend to scrape proprietary datasets we haven't paid for, and we don't pretend our reasoning is grounded in something it isn't.

• Anthropic Claude as the underlying reasoning model. Heartwood does not train Claude on submitted prompts. Anthropic does not train on Heartwood API traffic. The model is the engine, not the source of truth on any given vendor.
• Public web research, used by the Deep Research path on the second pass when the question warrants it. Vendor docs, pricing pages, regulatory filings, public earnings reports, and reputable industry coverage. Not paywalled analyst content.
• Operator-grounded system prompts and reviewer instructions that encode mid-market IT decision patterns. These are written by operators with hands-on CIO and CTO experience and tuned against actual mid-market decision shapes. They're proprietary to Heartwood.
• The user's own context, supplied in the prompt: industry, revenue band, current stack, the decision driver, the timeline, the audience for the brief. The more of this a user gives us, the sharper the output.

On data handling: we use a two-table anonymization pattern in our database. The user identity table and the question content table are kept separate, joined only for the user's own brief history. This is a deliberate design choice, not an afterthought. It means that even with full database access, a Heartwood operator can't reconstruct "who asked what" without crossing a join boundary that's logged.

What we do not claim to know

Several categories of information are explicitly outside what a Heartwood brief can deliver. When a question lands in one of these gaps, the brief says so rather than guessing.

• Live vendor pricing on a specific quote. Pricing in a brief is a defensible range based on public list pricing and recent comparable deals. The number on your actual quote depends on the rep, the quarter, and the negotiation. We won't fabricate a precise figure.
• In-flight M&A activity or non-public vendor roadmaps. If a vendor is about to be acquired, divest a product line, or sunset a tier, we know what the public market knows. We don't have insider channels and won't pretend to.
• Anything proprietary to a single analyst firm. Heartwood doesn't carry a Gartner, Forrester, or IDC license. We don't quote their reports and we don't fake their conclusions. If a buyer needs an analyst-firm citation for a procurement committee, that's a legitimate reason to also buy a Gartner inquiry.
• Internal politics of the buyer's organization. We only know what the user tells us in the prompt. If the real blocker on a decision is a personality conflict between the CFO and the VP of IT, we won't see it unless the user names it.
• Real-time operational telemetry. We're not connected to your monitoring tools, your logs, your billing dashboards, or your CRM. Whatever the brief reasons about, the user supplied or we found in public sources.

How we treat low-confidence answers

When the model's confidence is low on a section, the brief surfaces a human_escalation_hint field with a flag and a short reason. That hint points the user to Seven Roots Consulting for a human second opinion. We don't paper over uncertainty with confident-sounding prose, because that's the failure mode that makes generic LLM advice dangerous on real decisions.

The brief is advisory. The buyer signs the decision. When the question is fuzzy, the data thin, or the situation outside our reasoning frame, we say so and route to a human. That backstop is part of the product, not a fallback.

What's not in scope yet

These are conscious gaps, not bugs. Each one is a deliberate decision about what to ship now versus what to add later, calibrated to where the product earns its keep first.

• Live integrations with CRM, ERP, ITSM, or billing systems. A brief is a snapshot of reasoning on the inputs the user provides. We don't pull from Salesforce, NetSuite, ServiceNow, or AWS Cost Explorer today.
• Real-time pricing feeds. Pricing in briefs is a range, not a quote. We don't pretend to know what a vendor will land on for your specific contract.
• Jurisdiction-specific legal advice. Briefs flag regulatory considerations (HIPAA, SOC 2, FINRA, GDPR) where they're material to a decision, but the brief is not a legal opinion and is not a substitute for counsel.
• Industry coverage outside our core list. The advisor panel covers infrastructure, growth CTO, and risk decisions across a defined set of industry specialists. If your industry is unusual (energy, defense, certain regulated verticals), the brief uses cross-industry patterns but won't carry a sector specialist's pattern library.

Versioning

This page is versioned. The current revision is v1.0, last updated 2026-05-04. When we change what data we use, what we don't claim to know, or how we treat low-confidence answers, we update this page and bump the version. The methodology page carries its own version stamp on the same cadence.

Signed by the Heartwood team at Seven Roots Consulting.

Contact

If something on this page is unclear, wrong, or out of date, or if you've spotted a category of source or limitation we should name explicitly, write us at panel@sevenrootsconsulting.com with the subject line "Sources and Limitations feedback." We aim to respond within two business days.