Who is responsible for the content?
Content is published by the Vail Valley AI Engineering Team. That is an organization-level author, not a substitute identity for an unnamed person. We do not create fictional staff profiles, reviewer biographies, credentials, or client quotes. If an individual later approves a public byline, their name and role can be added to the specific material they actually authored or reviewed.
What gets published?
A page should own a distinct user need. Service pages explain what a buyer can obtain and how to evaluate fit. Industry pages explain requirements or risks that genuinely change by sector. Location pages explain coverage and local operating context. Resource articles answer a decision or implementation question. We do not approve a new page merely because a keyword, town, or synonym can be inserted into an existing template.
Every collection entry has an intentKey. The build fails when two entries claim the same key. This is an editorial guardrail, not proof that every legacy page is unique; legacy overlaps are reviewed with search, engagement, conversion, and content evidence before consolidation.
Editorial status
Legacy means the page predates the current evidence model and has not completed a full review under this policy. Reviewed means the page has a review date, follows the current content model, and has been checked for unsupported claims, attribution, intent, and source references. Reviewed does not mean independently audited, endorsed by a regulator, or guaranteed to remain current forever.
Sources and factual claims
Factual claims that can change or that affect a consequential decision should point to an authoritative source. Content stores stable sourceRefs; source titles, publishers, URLs, and access dates live in a central registry so a citation can be corrected in one place. Primary sources—official documentation, government data, standards, statutes, product documentation, and original research—are preferred over summaries.
We distinguish a sourced fact from an inference. Local population or land-use data may describe context, but it cannot establish a business's demand, savings, or return. Product documentation can establish a feature, but it cannot prove that the feature was configured or effective in a particular deployment.
Examples, demos, and client evidence
Hypothetical scenarios and interface sketches must be labeled as illustrative. Fictional names, numbers, sample records, or flows cannot be described as a client deployment. A case study may be published only with permission or in a verifiably anonymized form, and it must identify the scope, baseline, measurement method, dates, limitations, and whether the client confirmed the account.
AI-assisted work
Software tools, including language models, may assist with research organization, drafting, editing, or quality checks. They do not replace editorial responsibility. The engineering team remains accountable for the published page, verifies factual claims against the cited source, and removes generated filler, unsupported conclusions, and wording designed primarily to evade similarity checks.
Updates and conflicts
Material updates receive a new dateModified. A full review receives a reviewedAt date. Commercial relationships, referrals, or vendor partnerships that materially affect a recommendation should be disclosed on the relevant page. No payment can purchase a factual conclusion, ranking claim, testimonial, or editorial status.
See the methodology for measurement rules and the corrections policy for reporting an error.