Skip to main content

Decision Log

Purpose​

Decision Log records major revenue, positioning, offer, channel, partner, and operating decisions for MetaCTO.

It is part of the Revenue Context System.

Its job is to prevent the team and agents from re-litigating decisions that have already been made.

It answers:

  • What did we decide?
  • Why did we decide it?
  • Who owns it?
  • What docs, campaigns, pages, vendors, and agents does it affect?
  • What would cause us to revisit it?
  • What changed because of the decision?

The Decision Log should not capture every passing thought.

It should capture decisions that change how MetaCTO sells, markets, positions, builds, measures, or operates revenue work.

Core Principle​

Decisions should compound, not disappear. MetaCTO is moving quickly.

That means decisions are being made across:

  • positioning
  • ICPs
  • offers
  • paid channels
  • partner relationships
  • thought leadership
  • website
  • agents
  • vendors
  • proof
  • sales motion
  • operating cadence

Without a Decision Log, those decisions get scattered across Slack, docs, calls, screenshots, and memory.

The standard:

If a decision changes what the team says, sells, builds, funds, measures, or prioritizes, log it.

What Belongs in the Decision Log​

Log decisions about​

  • company positioning
  • ICP focus
  • offer hierarchy
  • SKU naming
  • paid budget allocation
  • channel strategy
  • partner priorities
  • sales motion
  • source-of-truth rules
  • agent permissions
  • website messaging
  • proof claims
  • vendor roles
  • strategic creative investments
  • major language choices
  • operating cadence
  • campaign stops/starts
  • major objections and rule changes Do not log
  • minor copy edits
  • routine task assignments
  • daily scheduling
  • one-off brainstorm notes
  • unvalidated ideas
  • every Slack opinion
  • every ad variant
  • every content topic

If the item is useful but not a decision, put it in:

  • 99 TODO
  • campaign backlog
  • research backlog
  • Source Conflict Log
  • Proof Library
  • Market Context
  • Buyer Context

Decision Entry Template​

Decision ID​

D-[YYYY-MM-DD]-[short-name]

Decision​

What was decided?

Status​

  • Active
  • Superseded
  • Needs Review
  • Reversed
  • Archived Date When was the decision made?

Owner​

Who owns the decision?

Context​

What was happening that made this decision necessary?

Rationale​

Why this decision?

Alternatives considered​

What else could we have done?

What this changes​

Which docs, pages, offers, campaigns, vendors, agents, or behaviors need to change?

What would cause us to revisit it​

What signal would make this decision wrong, incomplete, or outdated?

Source / Evidence​

Where did the supporting context come from?

Follow-up actions​

What needs to happen next?

Decision Status Definitions​

Active​

Current operating truth.

Needs Review​

Still in use, but needs validation.

Use when:

  • market signal changed
  • buyer response is weak
  • internal disagreement remains
  • data is incomplete
  • more than 90 days have passed without review

Superseded​

A newer decision replaced it.

Keep the old entry for history.

Reversed​

The team decided the prior decision was wrong.

Log why.

Archived​

Historical only. Do not use for current decisions.

Decision Categories​

Use one or more categories per entry.

  • Company
  • ICP
  • Offer
  • Language
  • Proof
  • Agent
  • Cadence
  • Market
  • Buyer
  • Partner
  • Channel
  • Source of Truth
  • Vendor
  • Creative
  • Website
  • Paid
  • Sales
  • Finance
  • Delivery

Initial Decision Log​

These are the initial decisions already made while building the Revenue Context System.

D-2026-04-ECE-flagship​

Decision​

Enterprise Context Engineering is the flagship offer and primary company-level commercial center of gravity.

Status​

Active​

Owner​

Founder Category

Company, Offer, Language, Channel, Website

Context​

MetaCTO is repositioning from a product development firm into a higher-value technical excellence and AI-native systems partner for growing mid-market companies. The earlier GTM strategy already identified a shift toward AI-native systems, production engineering execution, and a context/data infrastructure layer that connects company systems and makes them legible to AI.

Rationale​

ECE best unifies the company’s strongest strategic direction:

  • AI is easy to access, hard to operationalize.
  • The model is rarely the real blocker.
  • Companies need connected context, workflow fit, controls, evals, feedback, and production engineering execution.
  • MetaCTO should lead with the systems layer behind production AI.

The ECE follow-up deck reinforces that most AI projects stall after the demo because of fragmented context, no operational trust, poor workflow integration, and no improvement loop. It frames the problem as a systems engineering problem, not an AI capability problem.

Alternatives considered​

  • Lead with AEMI
  • Lead with Lightning Pods
  • Lead with Product Development
  • Lead with Agent Development
  • Lead with generic AI consulting
  • Lead with workflow automation

What this changes​

  • Homepage should make ECE the hero path.
  • Paid budget should prioritize ECE.
  • Thought leadership should educate toward ECE.
  • Agent Development, CAIO, and workflow automation should support ECE rather than compete with it.
  • S2A can remain a wedge, but not the flagship.

What would cause us to revisit it​

  • ECE language fails to generate qualified conversations after sustained testing.
  • Buyers consistently understand and buy a different offer more easily.
  • S2A or AEMI materially outperforms ECE as a strategic entry point and expansion path.
  • Market language shifts strongly away from context/production systems.

Follow-up actions​

  • Keep ECE as homepage center.
  • Build ECE paid landing page.
  • Build ECE one-pager and sales deck.
  • Build ECE visual framework.
  • Track qualified conversations from ECE language.

D-2026-04-growing-companies-ICP​

Decision​

Use “growing companies” as the primary ICP-facing language.

Status​

Active​

Owner​

Founder / Marketing Manager​

Category​

ICP, Language, Buyer, Website

Context​

“Startups” pulls MetaCTO toward the older MVP/product-development motion. “Enterprise clients” pulls the company toward enterprise theater and overbuilt transformation language. “Growing companies” is aspirational, self-identifying, and implies scale, complexity, data, systems, people, and new operating problems.

Rationale​

“Growing companies” lets mid-market buyers self-identify without feeling small or over-enterprised. It supports:

  • scattered context
  • manual handoffs
  • scaling complexity
  • operational leverage
  • AI accountability
  • systems that no longer match the business

The GTM strategy describes the newer revenue engine as targeting mid-market companies with larger, higher-value AI-native systems and recurring relationships, separate from the existing startup/SMB product development engine.

Alternatives considered​

  • Startups
  • SMBs
  • Enterprise
  • Mid-market only
  • Companies that depend on software
  • Software-enabled businesses

What this changes​

  • Website copy should prefer “growing companies.”
  • Paid and organic copy should avoid startup-first framing.
  • Product Development remains available, but should not dominate positioning.
  • ECE and S2A should speak to scaling complexity.

What would cause us to revisit it​

  • Paid and organic data shows another phrase produces better qualified demand.
  • Partners consistently use a stronger term.
  • Buyer interviews show “growing companies” is too broad.

Follow-up actions​

  • Use “growing companies” in Company Truth, Buyer Context, Channel Context, and website copy.
  • Avoid overusing “mid-market” in public copy, while keeping it as an internal targeting rule. D-2026-04-positioning-away-from-ai-enablement

Decision​

Do not position MetaCTO as generic AI enablement.

Status​

Active​

Owner​

Founder​

Category​

Company, Language, Offer

Context​

The GTM strategy records Nathaniel’s feedback that “AI enablement” is becoming commoditized and recommends positioning around technical excellence, engineering leverage, and production AI systems instead.

Rationale​

“AI enablement” sounds like workshops, tool rollout, training, and generic consulting.

MetaCTO’s stronger position is:

  • production engineering execution
  • context infrastructure
  • agent workflows
  • operational automation
  • technical leverage
  • production AI systems

The GTM strategy explicitly contrasts MetaCTO with generic AI consultancies that offer strategy, experimentation, and workshops, while MetaCTO offers production engineering execution.

Alternatives considered​

  • AI enablement
  • AI transformation
  • AI consulting
  • AI strategy
  • AI automation agency

What this changes​

  • Avoid “AI enablement” as primary positioning.
  • Use AEMI carefully as engineering enablement only where appropriate.
  • Lead with systems, context, production workflows, and measurable leverage.

What would cause us to revisit it​

  • Buyer language clearly demands “AI enablement” and converts better without weakening positioning.
  • A specific campaign uses the term as a bridge, not core positioning.

Follow-up actions​

  • Remove “AI enablement” from core messaging where it implies generic consulting.
  • Keep “engineer enablement” only in AEMI/Jamie contexts.

D-2026-04-language-triad​

Decision​

Use “Trusted Context. Usable Outputs. Reliable Actions.” as the core ECE loop where appropriate.

Status​

Active​

Owner​

Founder / Marketing Manager​

Category​

Language, Offer, Website

Context​

The language emerged while defining how MetaCTO should explain the ECE loop without overusing “reliable” or “trusted” everywhere.

Rationale​

The three-part loop maps cleanly to what production AI needs:

  • Trusted Context: AI can use the right business context.
  • Usable Outputs: outputs are structured, useful, and reviewable.
  • Reliable Actions: action happens with controls, permissions, and workflow fit.

The ECE deck similarly describes a mature system as requiring context, a meaning layer, execution, and control, including RBAC, audit logs, evals, traces, feedback, and cost visibility.

Alternatives considered​

  • Trusted Context, Reliable Outputs, Reliable Actions
  • Trusted Context, Confident Outputs, Trusted Actions
  • Governed Actions
  • Reliable Actions everywhere
  • No triad

What this changes​

  • Use the triad as a framework, not as copy filler.
  • Do not force the words into every section.
  • Use it especially when explaining ECE, agent systems, and production AI.

What would cause us to revisit it​

  • Buyers do not understand “Reliable Actions.”
  • “Usable Outputs” feels too weak in sales.
  • Another phrase performs better in paid or sales conversations.

Follow-up actions​

  • Add to Language System.
  • Use on ECE page and sales deck where it clarifies the system.
  • Test in paid and LinkedIn.

D-2026-04-may-paid-focus

Decision​

May paid budget is limited to ECE and Spreadsheet to App, split 80% ECE / 20% S2A.

Status​

Active​

Owner​

Founder / Marketing Manager / Matt N​

Category​

Channel, Paid, Offer, Website

Context​

MetaCTO is shifting its paid strategy away from legacy MVP App Development and AEMI paid campaigns. The newer strategy needs paid to validate the flagship and one concrete wedge.

The earlier GTM strategy included increasing LinkedIn, Facebook, and PPC, plus AEMI outbound and remarketing, but the current decision narrows paid focus to avoid diluting the rebrand and to prevent old demand patterns from controlling the new market position.

Rationale​

ECE needs education and buyer-language testing.

S2A is concrete, searchable, and pain-led.

AEMI remains important, but is better suited for partner, PE, direct, and organic channels right now.

MVP App Dev pulls the company toward the old inbound startup/product-development motion. The GTM strategy explicitly identifies the older inbound engine as startup/SMB product development driven by Google Ads, SEO, Clutch, referrals, and LinkedIn.

Alternatives considered​

  • Continue MVP App Dev paid spend.

  • Run paid budget across all offers.

  • Fund AEMI paid campaigns.

  • Put all paid budget into ECE.

  • Put all paid budget into S2A. What this changes

  • Matt N should focus May paid work on ECE and S2A.

  • AEMI paid campaigns paused.

  • MVP App Dev paid campaigns paused.

  • Landing pages must support ECE and S2A.

  • Paid scorecard should evaluate ECE and S2A only.

What would cause us to revisit it​

  • ECE produces no qualified conversations after meaningful testing.
  • S2A outperforms and expands into larger opportunities.
  • AEMI gets strong partner proof and becomes ready for paid again.
  • Attribution or tracking is too broken to evaluate spend.

Follow-up actions​

  • Pause AEMI paid.
  • Pause MVP App Dev paid.
  • Build ECE paid landing page.
  • Build S2A paid landing page.
  • Track by SQLs and qualified conversations, not leads alone.

D-2026-04-ECE-paid-language​

Decision​

ECE paid campaigns should use customer language, not internal category language.

Status​

Active​

Owner​

Marketing Manager / Matt N​

Category​

Paid, Channel, Language, Buyer

Context​

Most buyers will not search for “Enterprise Context Engineering” yet. ECE needs education.

Rationale​

ECE paid should speak in terms buyers already recognize:

  • agents
  • workflows
  • AI outputs
  • generative AI
  • CRM and systems problems
  • data problems
  • disconnected systems
  • summaries
  • drafts
  • reports
  • follow-ups
  • AI workflows

The ECE deck makes the same point: buyers should care about connected systems, context, workflow execution, evals, feedback, observability, and control, but messaging should lead with outcomes and trust while keeping architecture behind the scenes until asked.

Alternatives considered​

  • Bid on “Enterprise Context Engineering.”
  • Lead with context operating system.
  • Lead with orchestration, MCP, or agentic architecture.
  • Lead with AI consulting.

What this changes​

  • ECE ad groups should test buyer-language paths.
  • Landing pages must bridge simple pain to ECE.
  • Search terms should feed Market Context, Buyer Context, SEO, and Language System.

What would cause us to revisit it​

  • Buyers start searching directly for context engineering.
  • Technical buyer campaigns perform better with category language.
  • Customer-language keywords produce too many low-quality leads.

Follow-up actions​

  • Build keyword groups around agents, workflows, outputs, data, systems, and production AI.
  • Add search-term review to weekly cadence.

D-2026-04-stop-model-choice-pain​

Decision​

Do not use weak models, model choice, or model selection as a primary buyer pain.

Status​

Active​

Owner​

Founder / Marketing Manager​

Category​

Language, Buyer, Website, Paid

Context​

The team aligned that buyers do not usually self-identify with “weak models” or “model choice” as the core pain.

Rationale​

The more recognizable pains are:

  • scattered context
  • disconnected systems
  • AI pilots not reaching production
  • inconsistent outputs
  • manual handoffs
  • no evals
  • no traceability
  • no workflow integration
  • no improvement loop The ECE deck supports this strongly: “The model is rarely the real blocker” and the missing pieces are context, controls, workflow fit, and improvement after launch.

Alternatives considered​

  • Better model selection
  • Model quality
  • Weak model outputs
  • LLM choice consulting

What this changes​

  • Remove model-choice pain from core messaging.
  • Replace with systems, context, output trust, workflow integration, and controls.
  • Use model choice only as technical implementation detail when relevant.

What would cause us to revisit it​

  • Technical buyer conversations show repeated explicit pain around model evaluation or model routing.
  • A specific CAIO or Agent Development offer needs model evaluation language.

Follow-up actions​

  • Update Language System.
  • Remove from website drafts, ads, and one-pagers where it appears as primary pain.

D-2026-04-AEMI-positioning​

Decision​

AEMI is training, tooling, workflow improvement, and measurement for companies with internal engineering resources so they can work better and faster with AI, increasing velocity or reducing cost.

Status​

Active​

Owner​

Founder / Jamie / Marketing Manager Category

Offer, Language, Buyer, Partner

Context​

AEMI should not be framed as broad business AI maturity. It is specifically for internal engineering teams and engineering leadership.

Rationale​

The AEMI deck defines AEMI as a 30-day executive assessment that measures whether AI is producing real engineering change, not just new cost. It evaluates systems, tools, workflows, and team behaviors across the full SDLC.

It also shows the buyer question clearly: leadership is spending more on AI but cannot answer whether AI is improving product throughput, where new bottlenecks are, whether they can ship more with smaller teams, or what the ROI is.

Alternatives considered​

  • Broad AI maturity assessment
  • General AI readiness
  • Business AI audit
  • Generic engineering audit
  • Paid campaign flagship

What this changes​

  • AEMI should target CTOs, engineering leaders, CFOs, PE partners, and boards.
  • AEMI should be partner/direct/organic in May.
  • AEMI proof should focus on velocity, cost, confidence, delivery, review cycle, adoption, and ROI.
  • Jamie should own much of the engineering enablement thought leadership.

What would cause us to revisit it​

  • Buyers respond better to broader AI maturity language without diluting the offer.
  • AEMI becomes the most effective entry point across PE and partner channels.
  • New proof suggests a stronger public framing.

Follow-up actions​

  • Update AEMI language in Offer Context and Buyer Context.
  • Use AEMI in PE partner materials.
  • Do not fund AEMI paid in May.

D-2026-04-S2A-wedge​

Decision​

Spreadsheet to App is a concrete paid wedge, not the flagship.

Status​

Active​

Owner​

Founder / Garrett / Marketing Manager​

Category​

Offer, Paid, Channel, Website

Context​

S2A is a strong, simple pain-point wedge for operational companies, especially companies where versioned spreadsheets, manual workflows, and reporting gaps create immediate friction.

Rationale​

S2A can capture practical demand more easily than abstract ECE language.

It also educates buyers toward:

  • cleaner data
  • internal tools
  • workflow structure
  • permissions
  • reporting
  • future AI readiness

But it should not become more important than ECE in the offer architecture.

Alternatives considered​

  • Make S2A a flagship offer.
  • Treat S2A as only product development.
  • Avoid S2A because it is not AI-forward enough.

What this changes​

  • S2A gets 20% of May paid budget.
  • Garrett leads S2A content.
  • S2A pages should be simple and pain-led.
  • Avoid overloading S2A with too much ECE language.
  • Use it as a bridge to Product Development, ECE, or Agent Development when appropriate.

What would cause us to revisit it​

  • S2A becomes the dominant source of qualified pipeline.
  • S2A leads fail to expand beyond low-value app requests.
  • S2A produces poor-fit buyers or too much commodity demand.

Follow-up actions​

  • Build S2A paid landing page.
  • Build S2A keywords around version confusion and spreadsheet pain.
  • Track whether S2A leads have expansion potential.

D-2026-04-remove-AI-exec-zero-person​

Decision​

Remove AI Exec Team and Zero-Person Company from the current public offer architecture.

Status​

Active​

Owner​

Founder​

Category Offer, Website, Language

Context​

These concepts were too distracting or too equal in weight with the primary offer architecture.

Rationale​

The current offer architecture should elevate ECE and clear supporting SKUs:

  • AEMI
  • Spreadsheet to App
  • Agent Development
  • Continuous AI Operations
  • Lightning Pods
  • Product Development

“Zero-Person Company” also risks creating the wrong autonomy/replacement frame.

Alternatives considered​

  • Keep them as public sub-SKUs.
  • Keep them as thought-leadership concepts.
  • Use them as future vision.

What this changes​

  • Remove from offer pages and nav.
  • Avoid using as active public SKUs.
  • Keep any useful underlying ideas internal unless strategically reintroduced.

What would cause us to revisit it​

  • Market demand emerges for these concepts.
  • They become useful as a private strategic narrative.
  • A future offer architecture requires them.

Follow-up actions​

  • Remove from homepage/offer nav.
  • Ensure agents do not pitch them. D-2026-04-agent-dev-CAIO-added

Decision​

Add Agent Development and Continuous AI Operations as supporting SKUs.

Status​

Active​

Owner​

Founder / Garrett / Jamie​

Category​

Offer, Agent, Channel

Context​

ECE needs supporting offers that help buyers understand specific production paths and after-launch operations.

Rationale​

Agent Development captures buyer interest in agents, but should generally route into ECE when context and systems matter.

Continuous AI Operations gives MetaCTO the after-launch layer for monitoring, evals, feedback, quality improvement, and compounding value.

The ECE deck identifies the need for evals, traces, feedback loops, observability, cost visibility, and a way to improve after launch.

Alternatives considered​

  • Make Agent Development the flagship.
  • Make CAIO a maintenance/support package.
  • Hide both under ECE only.

What this changes​

  • Add both to Offer Context.
  • Fold both into ECE education.
  • Do not run standalone paid campaigns for either in May.
  • Use Garrett for agent/architecture thought leadership.
  • Use Jamie for delivery/improvement loop thought leadership.

What would cause us to revisit it​

  • Agent Development produces a better market entry point than ECE.
  • CAIO becomes a strong recurring revenue motion after first clients.
  • Buyers find the SKU list too complex.

Follow-up actions​

  • Define one-pagers for both.
  • Add to website only where hierarchy remains clear.
  • Build CAIO after-launch content.

D-2026-04-thought-leadership-woven​

Decision​

Thought leadership is woven into campaigns, not treated as a standalone content stream.

Status​

Active​

Owner​

Marketing Manager / Founder​

Category​

Channel, Language, Vendor

Context​

Chris, Garrett, and Jamie each have distinct expertise. The question was whether thought leadership should stand alone or feed the channel strategy.

Rationale​

The operating model:

Channels distribute thought leadership. Campaigns focus it. People give it credibility.

This keeps thought leadership connected to qualified demand, partner support, proof, SEO, webinars, podcasting, and sales enablement.

The 2026 GTM strategy already called for thought leadership on AI-native engineering teams, context engineering, engineering productivity, and the P&L view of technology.

Alternatives considered​

  • Standalone thought leadership calendar.
  • Founder-only content.
  • Company-only content.
  • Campaign-only content without expert voice.

What this changes​

  • Thought leadership appears inside Channel Context.
  • Each expert has a lane.
  • Alex supports social repurposing.
  • Chris Mogni supports SEO/blog optimization.
  • Podcast booking agent routes guests by audience.
  • Cinco supports high-impact packaging when strategic.

What would cause us to revisit it​

  • Expert content becomes too hard to produce consistently.
  • One channel clearly benefits from a separate thought leadership system.
  • The Marketing Manager needs a separate editorial calendar doc.

Follow-up actions​

  • Create 30-day LinkedIn plan by expert lane.
  • Create podcast pitch angles by expert lane.
  • Build blog series by campaign and SME.

D-2026-04-thought-leadership-lanes​

Decision​

Chris, Garrett, and Jamie have distinct thought leadership lanes.

Status​

Active​

Owner​

Founder / Marketing Manager​

Category​

Channel, Language, Buyer

Decision Details​

  • Chris: industry, strategy, buyer narrative, market POV.
  • Garrett: systems design, agentic development, technical architecture, S2A.
  • Jamie: engineer enablement, ECE delivery, internal AI operating systems.

Rationale​

This gives MetaCTO three credible voices:

Chris explains why it matters. Garrett explains how the system works. Jamie explains how teams actually use it and improve it.

Alternatives considered​

  • One founder voice only.
  • Random thought leadership by availability.
  • Everyone posts on the same topics.
  • Outsource thought leadership entirely.

What this changes​

  • Content planning should route topics to the right expert.
  • Podcast booking should choose guests by audience.
  • Blog ownership should reflect expertise.
  • Sales assets can pull from the right expert voice.

What would cause us to revisit it​

  • One lane does not produce useful market signal.
  • Roles change.
  • Buyer feedback suggests a stronger voice mapping.

Follow-up actions​

  • Update Channel Context.
  • Brief Alex.
  • Brief podcast booking agent.
  • Build expert-lane content calendar.

D-2026-04-partner-nodes-first​

Decision​

Build the partner system around named high-trust nodes before broad partner categories.

Status​

Active​

Owner​

Founder​

Category​

Partner, Sales, Channel

Context​

The current named partner nodes include Michael Murray, Nathaniel/Macoto, Gary Noke, Gauge Capital, and PwC/diligence channel.

Rationale​

Early partner work should be relationship-led and founder-led.

The GTM strategy cautions not to rely on channel too early because the message needs refining, positioning is still evolving, and founders sell best initially.

Named nodes create:

  • trust transfer
  • market signal
  • warm access
  • proof opportunities
  • partner learning

Alternatives considered​

  • Build a generic partner program now.
  • Hire channel sales.
  • Treat all partners the same.
  • Ignore partner work until positioning is complete.

What this changes​

  • Partner Context starts with named relationships.
  • Founder owns strategic partner touches.
  • Marketing/Sales Ops support with assets and tracking.
  • Partner intros are treated as high-value trust transfers.

What would cause us to revisit it​

  • Partner volume grows beyond founder capacity.
  • One partner type becomes repeatable enough to systematize.
  • Messaging becomes stable enough for broader channel enablement.

Follow-up actions​

  • Build partner briefs.
  • Track partner source in HubSpot.
  • Create “when to introduce MetaCTO” checklist.

D-2026-04-Michael-Gary-Gauge-Nathaniel-priority​

Decision​

Prioritize Michael Murray, Gary Noke, Gauge Capital, and Nathaniel/Macoto as Tier 1 strategic partner nodes.

Status​

Active

Owner​

Founder​

Category​

Partner, Sales

Context​

These relationships are already connected to real opportunities or strategic leverage:

  • Michael introduced Spinutech and has PE relationships.
  • Gary Noke is a strategic executive champion through NINJIO.
  • Gauge Capital is connected through the NINJIO board and portfolio potential.
  • Nathaniel/Macoto is a board/strategy filter.

Rationale​

These are not abstract partner categories. They are specific trust nodes with potential for:

  • warm intros
  • proof
  • offer feedback
  • PE access
  • strategic positioning
  • portfolio opportunities

Alternatives considered​

  • Prioritize PE broadly.
  • Prioritize RevOps agencies.
  • Prioritize cloud partners.
  • Treat every partner equally.

What this changes​

  • Partner Context includes named nodes first.
  • Partner assets should be built around these use cases.
  • Founder time should prioritize these relationships.

What would cause us to revisit it​

  • A partner becomes inactive.
  • Another relationship produces stronger signal.
  • One named node does not convert to learning, proof, or pipeline.

Follow-up actions​

  • Build Michael-specific ECE brief.
  • Build Gary/NINJIO referral brief.
  • Build Gauge AEMI/PE brief.
  • Ask Nathaniel to review partner motion.

D-2026-04-source-of-truth-rules​

Decision​

Source of Truth defines canonical sources, and agents can draft and suggest but cannot silently overwrite canonical truth.

Status​

Active​

Owner​

Founder / Marketing Manager / Matt F​

Category​

Source of Truth, Agent, Operations

Context​

The Revenue Context System will include humans, docs, HubSpot, campaigns, vendors, and agents. Without source rules, agents could spread stale or conflicting context.

Rationale​

Agents should support the system, not become unmanaged sources of truth.

The internal platform thinking supports this distinction by separating context, execution, and control/observability. It describes source and skill events, auditability, evals, feedback, context SHA linkage, and generated deliverables from structured context rather than ad hoc deck-building. Alternatives considered

  • Let agents update sources freely.
  • Keep agents read-only forever.
  • Avoid agent involvement in revenue operations.

What this changes​

  • Agents can read, summarize, draft, and suggest.
  • Humans approve strategic updates.
  • HubSpot remains CRM source of truth.
  • Decision Log records major changes.
  • Proof Library governs public proof.
  • Source conflicts are logged.

What would cause us to revisit it​

  • Agents demonstrate repeated accuracy in narrow workflows.
  • A controlled update path is needed for speed.
  • A compliance or client risk requires stricter limits.

Follow-up actions​

  • Build agent access matrix.
  • Define Sales Ops Agent permissions.
  • Define Marketing Agent permissions.
  • Define update review rules.

D-2026-04-HubSpot-CRM-source​

Decision​

HubSpot is the CRM source of truth.

Status​

Active​

Owner​

Sales Ops Category

Source of Truth, Sales, Agent

Context​

Revenue context may exist in Apollo, email, Slack, call notes, and proposals, but pipeline truth needs one canonical CRM.

Rationale​

HubSpot should own:

  • contacts
  • companies
  • deals
  • lifecycle stage
  • deal stage
  • owners
  • next steps
  • sales activity
  • lead source, if maintained

Apollo can support outbound and enrichment, but should not become a parallel CRM.

Alternatives considered​

  • Apollo as CRM source.
  • Slack/email as practical truth.
  • Separate spreadsheets.
  • Agent-maintained CRM.

What this changes​

  • Sales Ops must keep HubSpot current.
  • Agents draft updates, not silently overwrite.
  • Campaign quality should be reviewed through HubSpot stages.
  • Partner source should be tracked in HubSpot.

What would cause us to revisit it​

  • HubSpot is replaced.

  • Another system becomes the CRM.

  • HubSpot data quality becomes too poor to trust without cleanup. Follow-up actions

  • Define required fields.

  • Reconcile open opportunities.

  • Add partner source and campaign source discipline.

  • Build Sales Ops Agent draft update workflow.

D-2026-04-channel-vendor-map​

Decision​

Channel vendors are part of Channel Context and must be tied to campaigns, owners, and success signals.

Status​

Active​

Owner​

Marketing Manager​

Category​

Vendor, Channel, Website, Paid, Creative

Decision Details​

Current vendor/support map:

  • Alex: social media
  • Matt N: paid media
  • Chris Mogni: SEO
  • Joe K: marketing web development
  • Podcast booking agent: podcast guesting
  • Matt F: revenue context agent development
  • Patrick Cinco / Cinco: fractional Creative Director

Rationale​

Vendors should not work from isolated instructions. Each vendor should know:

  • active campaign
  • buyer
  • offer
  • message
  • success signal
  • reporting cadence
  • what not to say

Alternatives considered​

  • Manage vendors ad hoc.
  • Keep vendor roles outside Revenue Context.
  • Let vendors define their own priorities.

What this changes​

  • Channel Context includes Channel Vendor Map.
  • Vendor briefs should be created.
  • Monthly vendor scorecard should be reviewed.
  • Vendor learnings should feed Revenue Context docs.

What would cause us to revisit it​

  • Marketing Manager creates a separate vendor operations doc.
  • Vendor roster changes.
  • A vendor becomes project-based or paused.

Follow-up actions​

  • Create briefs for each vendor.
  • Add vendor scorecard.
  • Assign campaign responsibilities.

D-2026-04-Joe-K-web-dev-role​

Decision​

Joe K supports marketing web development for the marketing team.

Status​

Active​

Owner​

Marketing Manager / Joe K​

Category​

Vendor, Website, Channel

Context​

Campaign success depends on fast, measurable web surfaces: landing pages, forms, tracking, page updates, blog publishing, webinar pages, and conversion paths.

Rationale​

Joe K’s role is distinct from strategy and creative direction.

  • Joe K builds and maintains marketing web surfaces.
  • Cinco elevates high-impact creative moments.
  • Marketing Manager owns page priority, copy coordination, and campaign requirements.

Alternatives considered​

  • Marketing Manager handles all web updates.
  • Cinco handles page implementation.
  • Joe K only handles general maintenance.
  • Paid vendor builds pages independently.

What this changes​

  • Joe K is added to Channel Vendor Map.
  • Website and landing page development layer belongs in Channel Context.
  • Joe K should be briefed early for ECE and S2A page work.
  • Web development scorecard should track page readiness and tracking.

What would cause us to revisit it​

  • Web work becomes too large for Joe K.
  • A new CMS/web process is introduced.
  • Page iteration becomes a bottleneck.

Follow-up actions​

  • Brief Joe K on ECE and S2A landing pages.
  • Create web brief template.
  • Add tracking/page QA fields to scorecards.

D-2026-04-Cinco-strategic-creative​

Decision​

Patrick Cinco, who goes by Cinco, is fractional Creative Director for high-quality, high-impact design needs and should be used sparingly and strategically.

Status​

Active​

Owner​

Marketing Manager / Founder​

Category​

Creative, Vendor, Website, Channel

Context​

MetaCTO needs premium creative support for assets where design quality affects trust, clarity, category perception, or conversion.

Rationale​

Cinco should not be used for everyday production.

Use him where creative direction can materially improve:

  • flagship ECE page

  • visual frameworks

  • strategic sales decks

  • partner one-pagers

  • high-value proof/case-study design

  • webinar/keynote visuals

  • campaign creative after message validation Alternatives considered

  • Use Cinco for everything.

  • Do not use creative direction at all.

  • Use only templates and internal production.

  • Treat Cinco as web developer.

What this changes​

  • Creative Direction Layer added to Channel Context.
  • Creative need added to experiment backlog.
  • Strategic creative scorecard added.
  • Joe K and Cinco roles are distinguished.

What would cause us to revisit it​

  • More strategic creative support is needed.
  • Budget constraints require less creative investment.
  • Routine assets begin consuming too much creative direction time.

Follow-up actions​

  • Identify first 2–3 assets worthy of Cinco.
  • Create creative brief template.
  • Keep routine assets out of Cinco’s queue.

D-2026-04-website-live-vs-language-system​

Decision​

The Language System defines intended truth; the live website shows current public truth. If they conflict, log a web update.

Status​

Active​

Owner​

Marketing Manager / Joe K​

Category Source of Truth, Website, Language

Context​

The website changes over time and may lag behind strategic decisions.

Rationale​

The live site is what buyers see, but it should not override the Revenue Context System if it is outdated.

The Language System and Decision Log should guide updates.

Alternatives considered​

  • Treat live site as canonical for all public language.
  • Treat docs as canonical and ignore website mismatch.
  • Let pages drift until next redesign.

What this changes​

  • Website mismatches become implementation gaps.
  • Joe K receives web update requests.
  • Marketing Manager owns copy alignment.
  • Decision Log captures strategic language shifts.

What would cause us to revisit it​

  • CMS workflow changes.
  • Website is rebuilt as direct expression of the Revenue Context System.
  • Agents begin managing web copy under approval.

Follow-up actions​

  • Add site audit to monthly cadence.
  • Track web update backlog.
  • Update ECE and S2A pages first.

D-2026-04-operating-cadence​

Decision​

Use the operating rhythm: Respond daily. Test weekly. Decide monthly. Recalibrate quarterly.

Status​

Active​

Owner​

Founder / Marketing Manager / Sales Ops​

Category​

Cadence, Channel, Sales, Agent

Context​

Revenue work includes daily sales/proposal responsiveness, weekly experiments, monthly reviews, and quarterly strategy updates.

Rationale​

Different work has different timing:

  • Sales response, follow-up, and proposals need daily speed.
  • Demand gen tests need weekly focus.
  • Channel and campaign decisions need monthly review.
  • Strategic positioning and system updates need quarterly recalibration.

Alternatives considered​

  • Day-specific responsibilities only.
  • Weekly planning only.
  • Fully reactive schedule.
  • Fully automated agent schedule.

What this changes​

  • Doc 8 Cadence defines review rhythm.
  • Doc 12 Channels uses weekly/monthly scorecards.
  • Agents can operate continuously, while humans review on cadence.
  • Proposals and follow-ups remain daily priorities.

What would cause us to revisit it​

  • Team size changes.
  • Agent operations mature enough for more automation.
  • Sales volume requires stricter SLA.

Follow-up actions​

  • Build weekly planning template.
  • Build monthly review template.
  • Add agent event-driven work to cadence.

D-2026-04-partner-intros-high-value​

Decision​

Treat partner intros as high-value trust transfers, not ordinary leads.

Status​

Active​

Owner​

Founder / Sales Ops​

Category​

Partner, Sales

Context​

Partners like Michael, Gary, Gauge, Nathaniel, and PwC/diligence channels can transfer credibility, not just names.

Rationale​

A partner intro carries reputational risk.

MetaCTO must:

  • respond fast
  • understand context
  • show senior judgment
  • avoid generic discovery
  • close the loop with the partner
  • protect trust

Alternatives considered​

  • Treat partner intros like inbound leads.
  • Route all partner intros through SDR first.
  • Automate partner follow-up aggressively.

What this changes​

  • Partner intros should be founder-aware.
  • HubSpot should track partner source.
  • Partner Context should update relationship intelligence.
  • Sales Ops should ensure fast follow-up.

What would cause us to revisit it​

  • Partner volume becomes too high.
  • A specific partner channel becomes scalable.
  • Partner lead quality drops.

Follow-up actions​

  • Create partner intro workflow.
  • Build intro email templates.
  • Build partner close-the-loop process.

Decision Log Table View​

Use this summary table for quick review.

Decision Decision Statu Owner Categor Revisit ID s y Trigger

D-2026-04 ECE is flagship Active Founder Offer / ECE fails -ECE-flags Compan to create hip y qualified demand D-2026-04 Use growing companies as ICP Active Founder / ICP / Buyer -growing-c language Marketin Languag data ompanies-I g e shows CP better term

D-2026-04 Avoid generic AI enablement Active Founder Compan Buyer -positionin y/ language g-away-fro Languag demands m-ai-enabl e it ement

D-2026-04 Trusted Context / Usable Outputs / Active Founder / Languag Buyers do -language- Reliable Actions Marketin e not triad g understan d it

D-2026-04 May paid = 80% ECE / 20% S2A Active Founder / Paid Poor -may-paid- Marketin signal or focus g / Matt tracking N failure

D-2026-04 ECE paid uses buyer language Active Marketin Paid / Category -ECE-paid- g / Matt Languag search language N e emerges

D-2026-04 Kill model choice as primary pain Active Founder Languag Technical -stop-mod e buyer el-choice-p demand ain changes

D-2026-04 AEMI = engineering AI Active Founder / Offer Better -AEMI-posi training/tooling/workflow/measurem Jamie market tioning ent frame appears

D-2026-04 S2A is concrete paid wedge, not Active Founder / Offer / S2A -S2A-wedg flagship Garrett Paid dominates e pipeline

D-2026-04 Remove AI Exec Team and Active Founder Offer Future -remove-AI Zero-Person Company strategy -exec-zero needs -person them D-2026-04 Add Agent Development and CAIO Active Founder / Offer SKU -agent-dev Garrett / complexit -CAIO-add Jamie y hurts ed clarity

D-2026-04 Thought leadership woven into Active Marketin Channel Needs -thought-le campaigns g/ separate adership-w Founder editorial oven system

D-2026-04 Chris/Garrett/Jamie lanes Active Founder / Channel Lanes fail -thought-le Marketin to adership-la g produce nes signal

D-2026-04 Named partner nodes before broad Active Founder Partner Repeatabl -partner-no program e partner des-first category emerges

D-2026-04 Prioritize core named nodes Active Founder Partner Nodes -Michael-G stop ary-Gauge producing -Nathaniel- value priority

D-2026-04 Agents draft, humans approve Active Founder / Source / Controlled -source-of- canonical truth Matt F Agent automatio truth-rules n matures

D-2026-04 HubSpot is CRM source of truth Active Sales Source / CRM -HubSpot- Ops Sales changes CRM-sour ce

D-2026-04 Vendors tied to campaigns and Active Marketin Vendor Vendor -channel-v metrics g model endor-map changes

D-2026-04 Joe K owns marketing web dev Active Marketin Website Web -Joe-K-we support g / Joe K / Vendor bottleneck b-dev-role changes D-2026-04 Cinco used sparingly for strategic Active Marketin Creative Creative -Cinco-stra creative g/ needs tegic-creati Founder change ve

D-2026-04 Language System defines intended Active Marketin Website Web -website-li truth g / Joe K / Source system ve-vs-lang changes uage-syste m

D-2026-04 Respond daily / test weekly / decide Active Founder / Cadence Team or -operating- monthly / recalibrate quarterly Marketin volume cadence g changes

D-2026-04 Partner intros are trust transfers Active Founder / Partner / Partner -partner-int Sales Sales volume ros-high-v Ops scales alue

When to Add a New Decision​

Add a new Decision Log entry when any of these happen:

Offer changes​

  • new SKU added
  • SKU removed
  • offer renamed
  • offer hierarchy changes
  • pricing anchor changes
  • offer becomes paid focus
  • offer is paused

Channel changes​

  • budget allocation changes
  • channel is paused or scaled
  • paid campaign focus changes
  • new vendor added
  • attribution rules change Positioning changes
  • new core message
  • ICP language changes
  • website hero changes
  • major phrase adopted or banned
  • new proof claim approved

Sales changes​

  • pipeline stage definition changes
  • HubSpot source-of-truth rule changes
  • partner-intro workflow changes
  • outbound motion changes
  • qualification rules change

Agent changes​

  • agent gains new update permission
  • agent output becomes canonical for a workflow
  • new revenue agent launched
  • agent evaluation standard changes

Vendor changes​

  • vendor added
  • vendor paused
  • vendor scope changed
  • new reporting standard added
  • new owner assigned

Decision Review Cadence​

Weekly​

Review:

  • new decisions from the week
  • open decision drafts
  • decisions blocking execution
  • decisions affecting paid or sales

Monthly​

Review:

  • active decisions from the prior month
  • channel decisions
  • vendor decisions
  • source-of-truth conflicts
  • buyer or campaign signals that may require a decision change

Quarterly​

Review:

  • company positioning
  • ICP focus
  • offer hierarchy
  • ECE flagship status
  • AEMI role
  • partner strategy
  • source-of-truth rules
  • agent permissions
  • major vendor roles

Decision Change Workflow​

When a decision changes:

  1. Create a new Decision Log entry.
  2. Mark the old decision as Superseded or Reversed.
  3. Explain why the change happened.
  4. Update affected docs.
  5. Update website or assets if needed.
  6. Brief vendors if affected.
  7. Brief agents if affected.
  8. Add tasks to 99 TODO if execution is required. Do not silently edit history.

Keep the old decision visible for context.

Decision Log Agent Rules​

Agents may:

  • read Decision Log
  • cite Decision Log internally
  • draft new entries
  • suggest conflicts
  • flag stale decisions
  • suggest affected docs/assets
  • summarize decisions for humans

Agents may not:

  • create active decisions without human approval
  • mark decisions as reversed without human approval
  • change offer hierarchy
  • change paid budget
  • approve proof claims
  • update website copy based only on inferred decisions
  • brief vendors without approval

Agent output standard:

  • cite the decision ID
  • state current status
  • identify affected docs
  • recommend next action
  • flag if human approval is needed

Decision Log Fields for Agents and​

Humans Use these fields in the actual doc/table if possible:

Field Description​

Decision ID Unique ID​

Decision Short statement​

Status Active / Needs Review / Superseded / Reversed / Archived

Date Decision date​

Owner Human owner​

Category Offer / Channel / Partner / etc.

Context Why it came up​

Rationale Why this choice​

Alternatives What else was considered​

Affected Docs Docs that must align​

Affected Assets Website, landing pages, decks, ads

Affected Vendors Alex, Matt N, Chris Mogni, Joe K, podcast booking, Matt F, Cinco

Agent Impact What agents should do differently​

Revisit Trigger What would cause review​

Follow-up Actions Tasks created​

Last Reviewed Date​

Notes Extra context​

Initial TODOs From Decision Log​

Add these to 99 TODO or the relevant owner backlog.

High priority

  1. Build ECE paid landing page.
  2. Build S2A paid landing page.
  3. Pause MVP App Dev paid campaigns for May.
  4. Pause AEMI paid campaigns for May.
  5. Brief Matt N on 80/20 May paid focus.
  6. Brief Joe K on ECE and S2A page needs.
  7. Brief Alex on Chris/Garrett/Jamie thought leadership lanes.
  8. Brief Chris Mogni on ECE and S2A SEO priority.
  9. Brief podcast booking agent on guest routing. 10.Brief Matt F on revenue agent permissions and source-of-truth rules. 11.Identify first strategic creative asset for Cinco. 12.Create partner intro workflow. 13.Create partner one-pager / “when to introduce MetaCTO” checklist. 14.Add partner source tracking in HubSpot. 15.Build ECE visual framework. 16.Build S2A keyword and ad copy set. 17.Build ECE keyword and ad copy set. 18.Create Source Conflict Log. 19.Create Revenue Agent Access Matrix. 20.Review homepage for language alignment.

Medium priority 21.Create AEMI PE one-pager. 22.Create ECE partner brief for Michael. 23.Create Gary/NINJIO referral brief. 24.Create Gauge AEMI/PE brief. 25.Build provider release content tracker. 26.Build 30-day LinkedIn content calendar. 27.Build podcast pitch list. 28.Build webinar topic list. 29.Build vendor scorecard. 30.Build web development scorecard. 31.Build creative direction scorecard. 32.Build Decision Log table view in working doc.

Final Standard​

Decision Log exists to keep MetaCTO’s revenue strategy coherent as the team moves quickly.

The standard is: If a decision changes what we say, sell, build, fund, measure, or prioritize, log it.

A good decision entry should make it clear:

  • what changed
  • why it changed
  • who owns it
  • what it affects
  • what would make us revisit it

The Revenue Context System can only improve if decisions become reusable context.

Do not let strategy live only in memory.

TODO​