Skip to main content

Source of Truth

Purpose

Source of Truth defines where MetaCTO’s revenue truth lives, how humans and agents should use it, and which source wins when information conflicts.

It is part of the Revenue Context System.

The Revenue Context System only works if humans and agents know:

  • where to find current truth
  • which source is canonical
  • which sources are supporting evidence
  • which sources are historical
  • which sources require human approval before changing
  • what agents can read
  • what agents can draft
  • what agents can update
  • what must be escalated to a human

This doc prevents the Revenue Context System from becoming another pile of notes.

It turns context into an operating layer.

Internal product thinking already frames the system as one that turns company data into answers, actions, workflows, and continuous improvement through feedback and evaluation. It also names a “Context Plane” for what the company knows, a “Context Model Plane” for what the data means, an “Execution Plane” for what the system can do, and a “Control + Observability Plane” for whether it is working and improving.

Core Principle

The system should know where truth lives. MetaCTO’s revenue work depends on many sources:

  • HubSpot
  • Apollo
  • Slack
  • email
  • docs
  • proposals
  • landing pages
  • analytics
  • ad platforms
  • call notes
  • partner conversations
  • proof assets
  • decision logs
  • agent outputs

No single tool contains the full truth.

But every important question should have a clear answer:

Where does the canonical truth live?

If the answer is unclear, the system should flag it instead of guessing.

Source of Truth vs Glossary

Source of Truth

A Source of Truth answers:

  • Where does this information live?
  • Who owns it?
  • How current is it?
  • What system wins if sources conflict?
  • Can agents update it?
  • Does it require approval?

Example:

Current opportunity stage lives in HubSpot. Slack may contain discussion. Email may contain buyer nuance. But HubSpot is the canonical source for current deal stage.

Glossary

A Glossary answers:

  • What does this term mean?
  • How should we use it?
  • What terms should we avoid?
  • Which terms are internal only?
  • Which terms are approved for external use?

Example:

Enterprise Context Engineering means the discipline of making company context usable by AI in production.

Recommendation

Keep glossary inside Doc 13 for now as:

Revenue Glossary

If it grows too large, split it later into:

Glossary

Source Categories

Canonical Sources

Canonical sources are the places where current truth lives.

Agents should treat these as the highest authority for their domain.

Examples:

  • HubSpot for current CRM records
  • Revenue Context docs for positioning and offer truth
  • website CMS / live site for current public messaging
  • ad platforms for current campaign spend and performance
  • accounting system for booked/recognized revenue
  • signed contracts / DocuSign for executed agreements
  • Decision Log for locked strategic decisions

Supporting Sources

Supporting sources provide context, evidence, and history, but they do not automatically override canonical sources.

Examples:

  • Slack discussion
  • email threads
  • call transcripts
  • meeting notes
  • draft docs
  • campaign brainstorms
  • vendor updates
  • podcast notes
  • conference notes
  • rough founder notes

Supporting sources are valuable, but they need interpretation.

Historical Sources

Historical sources explain what happened or why something changed. They should not be treated as current unless confirmed.

Examples:

  • old proposals
  • older board decks
  • prior positioning docs
  • old landing page copy
  • past campaign reports
  • archived strategy drafts
  • old SKU lists
  • superseded offer language

Working Sources

Working sources are active drafts or operational workspaces.

They are useful but unstable.

Examples:

  • current campaign drafts
  • pending landing page copy
  • in-progress proposal docs
  • agent draft outputs
  • open TODO lists
  • planning docs
  • content calendars

Working sources can become canonical only after review.

Canonical Source Map

Company and Revenue Strategy Information Canonical Supporting Owner Agent Source Sources Permission

Company 1 Company founder notes, Founder Read, draft Truth Truth board docs, edits homepage copy

ICPs 2 ICPs sales calls, Founder / Read, suggest HubSpot, Marketing updates partner notes Manager

Offer 3 Offer Context proposals, Founder Read, draft architecture website, sales edits notes

Supporting 4 Other Offers proposals, Founder / Read, draft offers / website, Marketing edits sub-SKUs delivery notes Manager

Language 5 Language LinkedIn, Marketing Read, draft System website, ads, Manager / edits sales calls Founder

Proof Library 6 Proof case studies, Marketing Read, draft reviews, Slack, Manager additions client emails

Agent 7 Agents agent outputs, Founder / Matt Read, draft Constitution system F updates prompts, ops notes

Operating 8 Cadence weekly plans, Founder / Read, draft Cadence review notes Marketing updates Manager

Market Context 9 Market provider docs, Marketing Read, draft reports, Manager updates conference notes

Buyer Context 10 Buyer call notes, Marketing Read, draft HubSpot, Manager / updates search terms Sales Ops

Partner 11 Partners CRM, email, Founder Read, draft Context Slack, founder updates notes

Channel 12 Channels ad platforms, Marketing Read, draft Context analytics, Manager updates vendor updates

Source of 13 Source of all system Founder / Read, suggest Truth Truth docs Marketing updates Manager

Decision Log 14 Decision meeting notes, Founder Read, draft Log Slack, docs entries

Revenue Systems Source Map

HubSpot

Canonical for

  • contacts
  • companies
  • deals
  • pipeline stage
  • lead source
  • lifecycle stage
  • owner
  • next step
  • task queue
  • sales activity
  • notes tied to records
  • MQL / SQL status, if defined and maintained
  • current opportunity value, if maintained

Supporting for

  • attribution
  • buyer language
  • objection patterns
  • campaign source quality
  • partner-sourced opportunities
  • sales cycle analysis

Not canonical for

  • final signed contract value
  • recognized revenue
  • full delivery status
  • strategic decisions
  • approved public proof claims
  • offer definitions
  • positioning

Rules

HubSpot is the CRM source of truth. If a deal exists elsewhere but not in HubSpot, the Sales Ops owner should either create or update the HubSpot record.

If HubSpot conflicts with a signed contract, the contract wins.

If HubSpot conflicts with accounting for recognized revenue, accounting wins.

If HubSpot conflicts with founder judgment on strategic opportunity quality, founder judgment may override scoring, but the reason should be logged.

Internal board materials already flagged “Revenue system truth” as a risk because HubSpot, DocuSign, and accounting were not fully reconciled, and called for monthly bookings / pipeline / revenue reconciliation as a mitigation.

Apollo

Canonical for

  • outbound prospecting lists, if Apollo is the current working outbound source
  • contact enrichment fields, where HubSpot is incomplete
  • prospecting sequences, if used
  • outbound campaign status, if maintained there

Supporting for

  • lead quality
  • account research
  • outbound experiments
  • target account discovery

Not canonical for

  • current deal stage
  • closed-won status
  • final lifecycle stage
  • signed agreements
  • actual pipeline value

Rules

Apollo supports outbound.

HubSpot owns the CRM record. If Apollo and HubSpot conflict on company/contact details, Sales Ops should review and decide which field should update HubSpot.

Do not let Apollo become a parallel CRM.

The Spinutech proposal is a useful cautionary example: it describes HubSpot, Apollo, and DarcyIQ operating in parallel rather than as a unified revenue operating system, with fragmented data and inconsistent lifecycle governance.

Slack

Canonical for

  • live discussion
  • informal decisions before logged
  • working context
  • team questions
  • quick updates
  • vendor coordination
  • founder commentary

Supporting for

  • buyer language
  • partner notes
  • sales context
  • campaign observations
  • decision rationale
  • proof leads
  • agent feedback
  • vendor activity

Not canonical for

  • final strategy
  • approved positioning
  • offer definitions
  • current deal stage
  • contract terms
  • revenue recognition
  • public proof claims Rules

Slack is context, not final truth.

If an important decision happens in Slack, it must be moved to the Decision Log.

If a proof claim appears in Slack, it must be moved to the Proof Library and approved before public use.

If a buyer phrase appears in Slack, it can be moved to Buyer Context or Language System as a candidate phrase.

Email

Canonical for

  • sent communications
  • buyer commitments, unless later superseded
  • partner intro context
  • negotiation history
  • stakeholder requests
  • client approvals, if explicit

Supporting for

  • buyer language
  • objections
  • follow-up history
  • partner relationship context
  • proposal context
  • proof leads

Not canonical for

  • final contract terms, if DocuSign or signed agreement exists
  • current CRM stage, if HubSpot has been updated
  • public claims, unless approved separately
  • strategic decisions, unless logged

Rules

Email can confirm what was communicated. Email should not replace HubSpot for pipeline status.

Important email context should be summarized into HubSpot, Partner Context, Buyer Context, or Decision Log as appropriate.

Google Drive / Docs / Wiki

Canonical for

  • Revenue Context System docs
  • current internal strategy docs
  • approved offer language
  • proof library
  • templates
  • partner briefs
  • campaign plans
  • decision log
  • working docs, when clearly marked as current

Supporting for

  • proposal drafts
  • meeting notes
  • historic planning
  • old strategy
  • research

Not canonical for

  • CRM stage
  • live ad spend
  • final signed contracts
  • recognized revenue
  • web production content unless synced with live site

Rules

Docs must be clearly labeled as:

  • current
  • draft
  • needs review
  • archived

Agents should not treat old drafts as current truth.

If the same topic appears in multiple docs, the numbered Revenue Context System doc wins unless superseded by the Decision Log.

Website / Live Pages

Canonical for

  • current public messaging
  • current public offer presentation
  • active CTAs
  • live page structure
  • public case-study claims
  • public proof currently in use

Supporting for

  • conversion analysis
  • message testing
  • buyer education
  • campaign routing

Not canonical for

  • deeper internal strategy
  • full offer definition
  • private proof
  • draft positioning
  • source-of-truth decisions

Rules

The live website shows what the market sees.

The Revenue Context System defines what the company believes.

If the website and Language System conflict, the Language System should be reviewed and the website should be updated or a decision should be logged. Joe K supports marketing web development and should be involved when source-of-truth changes require website updates.

Canonical for

  • active paid campaigns
  • spend
  • ad status
  • search terms
  • clicks
  • platform-reported conversions
  • campaign-level performance

Supporting for

  • buyer language
  • message testing
  • channel decisions
  • SEO ideas
  • landing page improvements

Not canonical for

  • SQL quality
  • pipeline quality
  • final attribution
  • revenue impact by itself

Rules

Ad platforms show channel activity.

HubSpot and pipeline review show lead quality.

Accounting and contracts show revenue.

Paid performance should be judged by qualified conversations, SQLs, meetings, pipeline, and learning, not platform metrics alone. This matches the Q2 board risk that paid spend must produce qualified pipeline, not vanity metrics.

Analytics / Website Tracking

Canonical for

  • page views
  • traffic sources, if configured correctly
  • conversion events, if tracking is reliable
  • form submissions
  • landing page performance
  • retargeting audiences

Supporting for

  • message testing
  • page prioritization
  • paid and SEO decisions
  • conversion improvements

Not canonical for

  • buyer fit
  • closed revenue
  • pipeline quality
  • strategic positioning

Rules

Analytics is useful only if tracking is clean.

If tracking is broken, the source must be marked unreliable until fixed.

Do not make major channel decisions from untrusted tracking.

DocuSign / Signed Contracts

Canonical for

  • signed terms
  • committed scope
  • contracted amount
  • signature date
  • legal agreement status

Supporting for

  • bookings reconciliation
  • delivery handoff
  • proposal accuracy
  • client proof timeline

Not canonical for

  • recognized revenue
  • delivery progress
  • pipeline stage before signature
  • campaign attribution

Rules

Signed contracts override HubSpot deal amount if there is a conflict.

HubSpot should be updated to match signed agreements.

Accounting should be reconciled against signed agreements.

Accounting / Finance System

Canonical for

  • invoiced revenue
  • recognized revenue
  • payments received
  • AR
  • financial reporting
  • revenue reconciliation
  • margin, if tracked

Supporting for

  • GTM budget decisions
  • profitability analysis
  • channel ROI
  • board reporting

Not canonical for

  • pipeline stage
  • buyer language
  • offer positioning
  • delivery status

Rules

Accounting wins for recognized revenue and payment status.

HubSpot wins for pipeline stage.

Decision Log wins for strategic GTM decisions.

Proposals

Canonical for

  • what was proposed to a prospect
  • scope presented
  • pricing presented
  • timeline presented
  • assumptions presented

Supporting for

  • offer evolution
  • buyer language
  • objections
  • proof claims
  • pricing patterns
  • delivery expectations

Not canonical for

  • final signed scope, if contract differs
  • current offer architecture
  • public messaging
  • closed-won amount

Rules

Proposals are evidence of what was sold or attempted.

They do not automatically update offer architecture.

If a proposal creates new language or offer structure that should persist, update Offer Context or Decision Log.

Call Transcripts / Meeting Notes

Canonical for

  • what was said in that conversation
  • buyer language
  • objections
  • pain points
  • stakeholder concerns

Supporting for

  • CRM updates
  • follow-up drafts
  • proposal input packs
  • Buyer Context
  • Proof Library
  • Partner Context

Not canonical for

  • current deal stage
  • final decisions
  • approved proof
  • current strategy

Rules

Call transcripts should feed HubSpot, Buyer Context, and Proof Library. The Sales Ops Agent may draft summaries, but humans should review high-value opportunity notes.

Revenue Agents

Canonical for

Nothing by default.

Agents are not sources of truth unless specifically granted update authority for a narrow field or workflow.

Supporting for

  • drafts
  • summaries
  • recommendations
  • proposed CRM updates
  • proof candidates
  • buyer-language extraction
  • campaign synthesis
  • decision drafts
  • follow-up drafts

Rules

Agents can read, synthesize, and draft.

Agents should not silently overwrite canonical sources.

Agent outputs should include source links, confidence level, and recommended action.

The internal platform architecture supports this distinction: actions like CRM updates, emails, document generation, and API calls belong in the execution plane, while control, observability, RBAC, audit logs, evals, and feedback loops govern whether the system is safe and improving.

Conflict Resolution Rules

Rule 1: Contracts beat CRM If signed agreement and HubSpot conflict, the signed agreement wins.

Update HubSpot.

Rule 2: Accounting beats CRM for revenue recognition If HubSpot and accounting conflict on recognized revenue, accounting wins.

Update reporting notes.

Rule 3: HubSpot beats Slack for pipeline If Slack says a deal moved but HubSpot does not, HubSpot remains canonical until updated.

Sales Ops should update HubSpot or flag the discrepancy.

Rule 4: Decision Log beats memory If founder memory and Decision Log conflict, review the issue.

Until changed, the logged decision is the operating truth.

If the founder changes the decision, log the new decision.

Rule 5: Language System beats old copy If an old landing page, old proposal, or old post uses outdated language, the Language System wins.

Update the asset if it is still active.

Rule 6: Live site shows public truth, but Language System defines intended truth If the live site conflicts with the Language System, that is an implementation gap.

Log it as a web update.

Rule 7: Proof Library beats anecdote No public proof claim should be used unless it is in the Proof Library or approved by Founder.

Rule 8: Agent output never beats a canonical source by default Agents can suggest updates.

They cannot become the authority unless explicitly configured and approved.

Agent Access and Update Rules

Default agent permissions

Agents may:

  • read approved Revenue Context docs
  • search supporting sources
  • summarize conversations
  • draft CRM updates
  • draft follow-ups
  • draft proof candidates
  • draft decision-log entries
  • draft campaign summaries
  • suggest source-of-truth conflicts
  • flag stale content
  • propose glossary additions

Agents may not automatically:

  • change offer architecture
  • change ICP definitions
  • approve public proof
  • change budget allocation
  • change active paid campaigns
  • send partner emails without approval
  • update signed contract data
  • modify recognized revenue
  • change source-of-truth hierarchy
  • overwrite canonical docs without review Agent update levels Level 1: Read only

Agent can read and cite sources.

Use for:

  • market scans
  • buyer research
  • partner research
  • campaign review
  • source conflict detection

Level 2: Draft update

Agent can draft suggested updates for human approval.

Use for:

  • Proof Library additions
  • Buyer Context updates
  • campaign summaries
  • Decision Log drafts
  • glossary additions
  • HubSpot notes

Level 3: Update with review

Agent can update selected fields but human reviews.

Use for:

  • CRM note drafts
  • task suggestions
  • meeting summary insertion
  • content calendar updates
  • campaign backlog updates

Level 4: Controlled execution

Agent can take bounded action with approval or strict rules. Use for:

  • creating a task
  • updating a non-sensitive CRM field
  • creating a draft email
  • generating a proposal input pack
  • tagging a proof candidate

Level 5: Autonomous execution

Not approved by default.

Only consider after:

  • repeated accuracy
  • clear audit logs
  • rollback path
  • narrow scope
  • human owner
  • eval coverage
  • clear business value

Stale Content Rules

Status labels

Every strategic doc or major asset should be marked:

  • Current
  • Draft
  • Needs Review
  • Outdated
  • Archived

Review timing

Review weekly

  • Proof Library
  • Decision Log
  • campaign backlog
  • channel scorecards
  • paid search terms
  • agent feedback
  • buyer language notes

Review monthly

  • Market Context
  • Buyer Context
  • Partner Context
  • Channel Context
  • website messaging
  • vendor scorecards
  • source conflicts

Review quarterly

  • Company Truth
  • ICPs
  • Offer Context
  • Language System
  • Agent Constitution
  • Source of Truth
  • Revenue Operating Cadence

Stale content rule

If a section has not been reviewed, used, or validated in 90 days, mark it:

Needs Review

If a section is superseded, mark it:

Outdated

If a document should not guide current decisions, mark it:

Archived

Agents should downgrade or ignore outdated sources unless the user asks for historical context.

Source Update Workflows

When a sales call happens

  1. Transcript or notes captured.
  2. Sales Ops Agent drafts summary.
  3. Human reviews important details.
  4. HubSpot updated with current next step.
  5. Buyer language captured if useful.
  6. Objections captured if useful.
  7. Proof candidates captured if useful.
  8. Proposal input pack created if needed.

Canonical updates:

  • HubSpot for deal status
  • Buyer Context for repeated buyer language
  • Proof Library for proof candidates
  • Decision Log only if a real decision was made

When a partner intro happens

  1. Email or Slack intro captured.
  2. Partner source logged.
  3. HubSpot record created or updated.
  4. Partner Context updated if relationship signal matters.
  5. Sales Ops schedules follow-up.
  6. Founder owns strategic response.
  7. Decision Log updated only if partner strategy changes.

Canonical updates:

  • HubSpot for deal/contact/company
  • Partner Context for relationship intelligence
  • Decision Log for major partner decisions

When a paid campaign runs

  1. Matt N manages paid execution.
  2. Ad platform tracks spend and search terms.
  3. Joe K ensures page/forms/tracking work.
  4. HubSpot captures leads and downstream stage.
  5. Marketing Manager reviews lead quality.
  6. Channel Context updated with learning.
  7. Decision Log updated if budget or campaign strategy changes.

Canonical updates:

  • ad platform for spend and campaign status
  • analytics for page behavior
  • HubSpot for lead quality and stage
  • Channel Context for learning
  • Decision Log for budget decisions

When website copy changes

  1. Source change comes from Language System, Offer Context, or Channel Context.
  2. Marketing Manager writes or approves copy.
  3. Cinco supports creative direction only if strategic.
  4. Joe K implements page update.
  5. Tracking and QA checked.
  6. Decision Log updated if the change reflects a strategic decision.

Canonical updates:

  • Language System for approved language
  • live site for public presentation
  • Source of Truth for ownership rules
  • Decision Log for strategic changes

When a proof item appears

  1. Proof candidate captured from call, Slack, email, review, metric, or result.
  2. Marketing Manager adds to Proof Library.
  3. Founder approves public use if needed.
  4. Asset created or updated.
  5. Website or sales materials updated if useful. Canonical updates:
  • Proof Library for claim
  • live site/sales assets for public use
  • Decision Log only if proof changes strategic positioning

When strategy changes

  1. Decision is made by Founder or approved owner.
  2. Decision Log entry created.
  3. Affected docs updated.
  4. Website/assets updated if needed.
  5. Agents and vendors briefed.
  6. Old language marked outdated.

Canonical updates:

  • Decision Log first
  • relevant Revenue Context docs second
  • website/assets third
  • vendor briefs fourth

Source Ownership Map

Source Owner Backup / Support Review Cadence

Company Truth Founder Marketing Manager Quarterly

ICPs Founder Marketing Manager Quarterly / Sales Ops

Offer Context Founder Marketing Manager Monthly / Quarterly Language System Marketing Manager Founder Monthly

Proof Library Marketing Manager Founder approves Weekly public claims

Agent Constitution Founder / Matt F Sales Ops / Monthly Marketing Manager

Revenue Operating Founder Marketing Manager Monthly

Cadence

Market Context Marketing Manager Strategy Agent Monthly

Buyer Context Marketing Manager Sales Ops Agent Monthly / Sales Ops

Partner Context Founder Sales Ops Monthly

Channel Context Marketing Manager vendors Weekly / Monthly

Source of Truth Founder / Marketing Sales Ops / Matt F Quarterly Manager

Decision Log Founder Marketing Manager Weekly / Sales Ops HubSpot Sales Ops Founder Daily / Weekly

Paid platforms Matt N / Marketing Sales Ops Weekly Manager

Website Marketing Manager Founder / Cinco Weekly during / Joe K campaigns

SEO Chris Mogni / Joe K Monthly Marketing Manager

Social Alex / Marketing Chris / Garrett / Weekly Manager Jamie

Podcast booking Podcast booking Chris Weekly / Monthly agent / Marketing Manager

Revenue agents Matt F / Founder Sales Ops / Weekly / Monthly Marketing Manager

Creative direction Cinco / Marketing Founder / Joe K Project-based Manager

Source Reliability Levels

Level 1: High reliability Use for operating decisions.

Examples:

  • signed contracts
  • accounting system
  • current HubSpot records, if maintained
  • approved Revenue Context docs
  • Decision Log
  • approved Proof Library claims
  • live ad platform data
  • live website

Level 2: Medium reliability Use with review.

Examples:

  • meeting notes
  • call transcripts
  • Slack discussions
  • email threads
  • campaign drafts
  • vendor updates
  • agent summaries
  • analytics data if tracking is partially trusted

Level 3: Low reliability Use only as signal.

Examples:

  • old decks
  • old proposals
  • outdated landing pages
  • unapproved proof claims
  • brainstorming notes
  • unreviewed AI outputs
  • stale docs
  • screenshots without date/context Agent rule Agents should state the reliability level when producing important recommendations.

Source Conflict Log

Use this when systems disagree.

Date Conflict Sources Owner Resoluti Updated Notes Involved on Source

HubSpot HubSpot Sales Contract HubSpot deal / Ops wins amount DocuSign does not match contract

Ad Google Marketin SQL Channel platform Ads / g quality Context shows HubSpot Manager wins conversio ns but HubSpot has poor lead quality

Website Website / Marketin Languag Website language Languag g e System differs e Manager wins from Languag e System

Slack Slack / Founder Review Decision says Decision needed Log decision Log changed but

Decision

Log not updated

Proof Proposal Marketin Needs Proof claim / Proof g approval Library appears Manager in proposal but not Proof Library

Revenue Glossary

Purpose

The glossary gives humans, vendors, and agents shared definitions.

It should prevent language drift.

It should answer:

  • what the term means
  • whether it is internal or external
  • when to use it
  • what to avoid Enterprise Context Engineering Definition

The discipline of making company context usable by AI in production.

Use externally?

Yes.

Use when

Talking about MetaCTO’s flagship offer and method for connecting systems, structuring context, producing usable outputs, and supporting reliable actions.

Avoid

Do not explain it only as data integration, RAG, or prompt engineering.

Revenue Context System

Definition

The internal context system that helps MetaCTO create demand, qualify opportunities, manage partner relationships, capture proof, align messaging, and improve revenue execution.

Use externally?

Usually no.

Use when

Talking internally about the GTM/revenue knowledge base and agent operating layer.

Avoid

Do not call it the whole company operating system yet.

Company Truth Definition

The foundational belief system behind MetaCTO’s positioning, offer architecture, ICPs, and language.

Use externally?

No, internal.

Use when

Aligning strategy, messaging, and agent behavior.

Trusted Context

Definition

The business context AI can safely and accurately use because it is connected, structured, permission-aware, and sourced.

Use externally?

Yes.

Use when

Explaining why generic AI outputs fail and why production AI needs better company context.

Usable Outputs

Definition

Outputs that are structured, reviewable, relevant to the workflow, and ready for a human or system to use.

Use externally?

Yes. Use when

Explaining what AI should produce: summaries, drafts, briefs, reports, updates, recommendations, and next steps.

Reliable Actions

Definition

Actions taken across systems with the right permissions, controls, review paths, and auditability.

Use externally?

Yes, but sparingly.

Use when

Explaining the move from AI drafts to real workflow execution.

Production AI

Definition

AI that is used in real business workflows with context, controls, measurement, and ownership.

Use externally?

Yes.

Use when

Contrasting real operational systems with demos, pilots, or experiments.

Production Agent

Definition An AI agent with a clear role, defined context, tool access, boundaries, evaluation, monitoring, and human review paths.

Use externally?

Yes.

Use when

Talking about Agent Development, ECE, and CAIO.

Continuous AI Operations

Definition

The operating layer that keeps production AI systems useful, measurable, and improving after launch.

Use externally?

Yes.

Use when

Talking about evals, monitoring, feedback loops, improvement, and expansion after first system launch.

Avoid

Do not position it as basic maintenance.

AEMI

Definition

Training and tooling for companies with internal engineering resources so they can work better and faster with AI, increasing velocity or reducing cost.

Use externally? Yes, with explanation.

Use when

Speaking to engineering leaders, CTOs, CFOs, and PE partners about measuring and improving AI impact across engineering.

Avoid

Do not make it the primary paid campaign in May.

Spreadsheet to App

Definition

A practical offer that turns critical spreadsheets into internal tools with cleaner data, permissions, workflows, and reporting.

Use externally?

Yes.

Use when

Speaking to operational companies with spreadsheet versioning, manual reporting, or field workflow pain.

Agent Development

Definition

Designing and building role-bound agents with the context, tools, constraints, and output standards needed for real work.

Use externally?

Yes.

Use when Buyer specifically asks for agents or when agent language is the entry point into ECE.

Lightning Pods

Definition

Ongoing AI-native engineering capacity for clients who need to keep shipping after the first system or product goes live.

Use externally?

Yes, but not as a primary homepage or paid focus right now.

Use when

A client needs ongoing implementation capacity.

Context Layer

Definition

The connected, structured, permission-aware layer that makes company knowledge usable by AI.

Use externally?

Yes, with plain explanation.

Avoid

Do not overuse if the buyer is nontechnical.

Source of Truth

Definition

The canonical place where current information lives for a specific domain. Use externally?

Sometimes.

Use when

Explaining CRM, data, reporting, spreadsheet, or context quality problems.

Decision Log

Definition

The internal record of major revenue and GTM decisions, why they were made, and what would change them.

Use externally?

No.

Use when

Preventing re-litigation and keeping agents aligned.

Buyer Language

Definition

The actual phrases buyers use to describe pain, need, urgency, fear, and outcomes.

Use externally?

No, internal.

Use when

Improving ads, landing pages, sales scripts, content, and agent outputs. Proof Library Definition

The source of approved claims, metrics, quotes, examples, and case-study material.

Use externally?

No as a term, yes as source material.

Use when

Checking whether a claim can be used publicly.

Source Request Template

Use this when asking someone to update or clarify a source.

Source Request

What needs to be clarified?

Why does it matter?

Sources involved

Current conflict or gap

Proposed canonical source

Owner

Deadline

Should this update the Decision Log?

Yes / No

Agent Source Citation Standard

When agents produce revenue outputs, they should show their work without overwhelming the user.

For internal recommendations

Agents should include:

  • sources used
  • confidence level
  • conflicts found
  • recommended update
  • human approval needed

For external-facing drafts

Agents should not include raw internal citations in client-facing copy.

They should instead:

  • use approved proof only
  • avoid unapproved claims
  • flag unsupported claims
  • suggest proof needed

For source conflicts Agents should say:

  • “HubSpot says X.”
  • “Slack/email suggests Y.”
  • “Decision Log says Z.”
  • “Recommended resolution: update HubSpot or log a new decision.”

First 30-Day Rollout

Week 1: Define canonical sources Actions:

  • confirm HubSpot fields that matter
  • confirm where Decision Log lives
  • confirm where Proof Library lives
  • confirm where Revenue Context docs live
  • confirm where campaign performance is reviewed
  • confirm website update workflow with Joe K
  • confirm public proof approval process

Output:

Canonical Source Map v1

Week 2: Clean revenue system truth Actions:

  • reconcile top open opportunities
  • compare HubSpot, proposals, signed agreements, and accounting
  • identify missing partner source fields
  • identify missing lead source fields
  • identify untracked expansion opportunities
  • create source conflict log

Output:

Revenue Source Conflict Log v1 Week 3: Agent permissions Actions:

  • define what Sales Ops Agent can read
  • define what Marketing Agent can read
  • define what Strategy Agent can read
  • define what agents can draft
  • define what requires approval
  • define what agents cannot touch

Output:

Revenue Agent Access Matrix v1

Week 4: Glossary and stale content cleanup Actions:

  • approve glossary terms
  • mark outdated docs
  • update Language System if needed
  • update website if needed
  • move key decisions into Decision Log
  • archive superseded language

Output:

Source of Truth v1 locked

Final Standard

Source of Truth exists to keep the Revenue Context System usable, current, and safe.

The standard is: Every important revenue question should have a canonical source, an owner, and an update path.

The glossary is part of this doc because shared language is part of source truth.

But the Source of Truth doc is bigger than a glossary.

It defines:

  • where truth lives
  • who owns it
  • what agents can do with it
  • what happens when sources conflict
  • when content becomes stale
  • how strategy changes propagate into systems, pages, campaigns, agents, and vendors

The Revenue Context System only compounds if truth stays organized.

Decision Log