FIN Intra GTM Strategic Recommendations

Date: 2026-05-13 Status: Draft v0.1 Related audit: docs/audits/FIN_INTRA_GTM_PLANNING_CODEBASE_GAP_AUDIT_2026-05-13.md

1. Read On The Direction

The human projection layer is not cosmetic. It is the missing product layer.

The event store and agent-optimized data model give FIN truth, memory, and actionability. But a company does not adopt a system only because agents can query it. People need to see it, trust it, edit around it, argue with it, approve it, and use it in meetings. The intranet/projection layer is the bridge between operational truth and organizational trust.

That makes the intranet more than a wiki:

  • it is the human-readable projection of the business
  • it is the agent-readable corpus of company context
  • it is the proof surface for Nathel and future buyers
  • it is the operations control layer for FIN
  • it is the adoption layer for portals, customer collaboration, and executive agents

This is strategically important because it turns FIN from “an agent that does tasks” into “the living operating memory of the business.”

2. Strongest Parts Of The Plan

2.1 The three-plane model is the moat

Plane 1 private workspace, Plane 2 relationship data, and Plane 3 universal produce intelligence are a clean strategic explanation. It gives FIN a reason horizontal agents cannot simply copy the answer quality.

Recommendation: keep using this model in product, sales, and engineering docs. It should become part of the external narrative.

2.2 The intranet is the adoption layer

The intranet lets a non-technical buyer inspect the system. That matters. A warehouseman, buyer, owner, customer, and operator do not need to understand the event store. They need to see a useful projection of their world.

Recommendation: make “human-readable projections” a first-class platform capability, not a side feature.

2.3 Nathel is the right anchor

Nathel gives domain access, lived workflows, credibility, and customer relationships. The plan to use Nathel as a strategic customer rather than only a software buyer is directionally correct.

Recommendation: formalize the Nathel proof ladder before expanding scope.

2.4 Portal-only vs portal-plus-agent is a smart wedge

Not every Nathel customer or produce buyer is ready for an agent acting on their behalf. A portal-only path lets FIN deliver value and gather trust before asking for deeper automation.

Recommendation: make this a named segmentation:

  • portal-only: read/search/track
  • portal-plus-agent: ask/draft/escalate
  • agent-enabled operations: execute bounded actions

2.5 Tier 0 MCP is strategically useful but should stay low-touch

Tier 0 is good because it monetizes Knowledge Forge/FIN Central intelligence, validates external demand, and creates ecosystem gravity. It should not become the operational focus before Nathel proof and intranet foundation.

Recommendation: keep Tier 0 private beta, read-only, versioned, and low-support.

2.6 FIN Central is necessary before multi-tenant scale

The plan correctly identifies that multi-tenant deployments need an operator control plane. Without FIN Central, every tenant launch becomes a manual memory exercise.

Recommendation: ship FIN Central readiness as read-only status first, then add mutating controls after the status model is reliable.

3. Main Strategic Risks

3.1 Seven surfaces can become seven unfinished products

The seven-surface map is useful, but it should not be treated as seven things to build at once.

Recommendation: keep the surface map, but sequence it:

  1. internal intranet and FIN Canon
  2. FIN Central control plane
  3. employee/customer portal slices
  4. portal-plus-agent flows
  5. marketplace
  6. public marketing site

3.2 Reverse projection can create trust problems

Two-way Obsidian/edit sync is powerful but dangerous. If edits from a markdown vault can mutate operational truth without review, the system becomes hard to audit.

Recommendation: v1 should be proposal-based. A human or deterministic policy gate approves any edit that becomes an event or production doc.

3.3 Executive agents can become bespoke consulting

Tier 3 exec agents are compelling, especially with Orgo, voice, and visible operations. But they can absorb infinite founder time if not constrained.

Recommendation: define Tier 3 as a premium packaged offer with a small number of repeatable workflows, not a blank-check personal automation service.

3.4 Federal posture can become premature complexity

Federal positioning matters, but it can consume architecture time before the commercial wedge proves itself.

Recommendation: build federal readiness as metadata, auditability, provider routing, and proof bundles now. Delay federal-specific runtime forks until there is a concrete opportunity.

3.5 Knowledge Forge learnings must not blur tenant boundaries

The plan depends on shared produce intelligence, but tenant operational learning must never leak into universal intelligence without explicit policy.

Recommendation: create an “aggregate learning policy” before using tenant data to improve FIN Central KB. Default to no cross-tenant promotion.

4. Product Enhancements

4.1 Rename the buyer-facing idea

“Human-agent projection layer” is precise internally. For customers, use a simpler phrase.

Candidate language:

  • “your company’s living operating wiki”
  • “a live company memory that your agent can use”
  • “your operations, documents, and decisions in one searchable place”
  • “an intranet that stays in sync with the business”

Recommendation: use “FIN Company Memory” or “FIN Operating Wiki” in GTM materials, while keeping “human-agent projection layer” as the engineering term.

4.2 Make the first projected docs concrete

Do not start with abstract graph features. Start with documents people already understand.

Recommended first doc types:

  1. Decision record
  2. SOP/runbook
  3. Nathel proof package
  4. Daily operational summary
  5. Customer portal page
  6. Vendor/customer dossier
  7. Load or QC event digest

4.3 Add a proof package product primitive

The proof package may be the killer internal object. It can connect:

  • events
  • artifacts
  • screenshots
  • agent summaries
  • before/after claims
  • stakeholder-specific impact
  • next commercial ask

Recommendation: make proof packages a doc kind and a FIN Central surface.

4.4 Make portal-only a deliberate product

Portal-only should not feel like “agent disabled.” It should feel like the lowest-risk way to start.

Positioning:

  • “Give customers visibility first.”
  • “Turn on agent assistance after trust is established.”
  • “Portal is read, agent is action.”

4.5 Treat DOCX as export, Markdown as source

The planning session already shows why markdown is attractive: version control, links, agent readability, and projection. DOCX is valuable for customer-facing deliverables and polished export, but it should not be the canonical source.

Recommendation: make Markdown canonical and DOCX generated/export unless a specific customer workflow requires Word as the active editor.

5. GTM Enhancements

5.1 Use a land-expand-control narrative

The tier plan is strong. It can be sharpened as:

  1. Land with intelligence or communication value.
  2. Expand into portals and agent-assisted workflows.
  3. Control operational surfaces once trust and data coverage are proven.

This avoids leading with ERP replacement too early.

5.2 Separate buyer promises by tier

Tier 1 promise:

  • “You get a produce-literate agent on email/SMS.”

Tier 2 promise:

  • “You get multi-channel operating assistance and a living company memory.”

Tier 3 promise:

  • “You get an executive operations agent with visible, high-touch support.”

Tier 4 promise:

  • “You operate the business on FIN.”

Tier 0 promise:

  • “Your agent/product gets produce intelligence through MCP.”

5.3 Add success metrics by offer

Tier 1:

  • response time saved
  • vendor/customer messages drafted
  • accepted draft rate
  • market questions answered

Tier 2:

  • number of connected vendors
  • portal active users
  • weekly agent-assisted workflows
  • customer-visible issue resolution

Tier 3:

  • exec time saved
  • calls/emails triaged
  • strategy briefs generated
  • visible workstation tasks completed

Tier 4:

  • operational workflows on FIN
  • event coverage
  • QC catches
  • inventory/order cycle improvements
  • audit completeness

Tier 0:

  • tool calls
  • active keys
  • repeat queries
  • external citations/use cases

6. Architecture Enhancements

6.1 Define “content graph” explicitly

The intranet is easier to build if the graph model is explicit:

  • doc
  • artifact
  • event
  • actor
  • customer
  • vendor
  • lot/load
  • commodity
  • workflow
  • proof package

Each node has permissions, provenance, and citations.

6.2 Build read projections before write workflows

The first versions should help users see and understand. Once trust exists, write/edit/action workflows can be added.

Recommended sequence:

  1. read/search/view
  2. annotate/propose
  3. approve/commit
  4. automate bounded updates

6.3 Keep GitHub, events, and knowledge in distinct roles

Do not let GitHub become the operational database. Do not let the event store become a document editor. Do not let knowledge pretend to be the original source.

Recommended framing:

  • GitHub is authored source history.
  • Events are operational truth.
  • Knowledge is the queryable projection/index.
  • Operational memory is semantic recall.
  • Storage is bytes.

6.4 Make every projection explain itself

Every generated doc should answer:

  • What source events/docs/artifacts created this?
  • When was it generated?
  • Which actor/system generated it?
  • What is stale?
  • What is hidden because of permissions?

This is how the intranet earns trust.

7. Suggested Near-Term Decisions

DecisionRecommendation
Canonical planning formatMarkdown canonical, DOCX export
First rendererQuartz for pilot, Workspace reader for product
First customer-facing surfacePortal-only customer view
First agent-facing surfacesearch_docs and get_doc over FIN Canon
First FIN Central additionTenant/vault/readiness status
First proof objectNathel proof package
First Tier 0 movePrivate beta with read-only produce intelligence
First Tier 3 moveOrgo contract spec, not code
Reverse projectionDraft/review only in v1

8. Bottom Line

The direction is right. The human projection intranet is the missing layer because it makes the event store legible to people and makes company context durable for agents. The GTM work is also important because it clarifies that FIN is not one monolithic sale. It is a ladder: intelligence, communication, portals, executive assistance, then operational ERP.

The main enhancement is discipline: make the intranet the product foundation, make Nathel the proof loop, make FIN Central the control plane, keep Tier 0 MCP low-touch, and keep every projection tied to provenance and permissions.