A LOOKBOOK · FIN CENTRAL × NATHEL TENANT INTRANET

A living
knowledge layer
& a working
company brain.

Most intranets are filing cabinets. Most ERPs are forms and tables. FIN's intranet is something new: a single living document layer that the humans of a produce business and the agents working alongside them can both read, reason over, and cite.

AudienceNon-technical
ScopeCentral + Tenant
Tenant pilotNathel · Hunts Point
StatusLive · staging
The shape of the problem

Most company knowledge
is a graveyard.

Walk into any 80-year-old produce distributor and ask the simple question — how do we handle a load of California blackberries that arrived at 38°F instead of 32°F? — and the answer lives in five places at once. It's in a printed SOP nobody updated since 2018. It's in the head of a foreman who's been doing it for thirty years. It's in a Teams chat from last Tuesday. It's in the ERP under a screen no one navigates to anymore. And it's in a PDF user guide on a shared drive.

The information exists. It just can't be retrieved by a system, or cited by a person, or used by the AI agent the company is paying $50,000 a year to consult. The knowledge isn't dead. It's buried.

What the old way looks like

  • PDFs in a shared drive nobody searches
  • Wiki pages last edited in 2019
  • Tribal knowledge in three people's heads
  • ERP screens nobody navigates to anymore
  • Slack threads buried four channels deep
  • Spreadsheets with the canonical price list
  • Email attachments from a vendor in 2022
  • An AI agent that hallucinates because none of it is in its context
"The intranet is the brain. If the brain can't be read by the agent, you don't have an AI strategy. You have a chatbot." FIN design principle, 2026
What the FIN intranet actually is

Two intranets,
working as one.

FIN's intranet has two parts. The first is FIN Central — the universal knowledge layer that holds the produce industry's accumulated truth. Commodity profiles for 487 produce items. Variety details. Vendor histories. Regional patterns. Seasonal windows. FSMA compliance rules. The kind of knowledge that's true whether you're Nathel in Hunts Point or a future distributor in Salinas.

The second is the tenant intranet — for Nathel, this is nathel-intranet, a private repository that holds what's true today, in this warehouse, for this company. Today's arrivals. This load's QC outcome. That customer's order pattern. The morning pricing read from the GM. The PDF invoice that landed at arrivals@fintail.net at 6:14 AM.

The two layers fuse. When an agent looks up blackberry for Nathel, it doesn't just get the universal commodity profile, and it doesn't just get Nathel's last week of blackberry arrivals. It gets one document that contains both — the world's knowledge of blackberry composed with Nathel's lived operational reality on top.

487profiles
Commodities &
varieties on Central
2,620edges
Backlinks already
connecting entities
488files
Mirrored Central→tenant
in first sync
15subtypes
Signal event types
flowing live today
How it works

A three-rung taproot,
not a database.

The metaphor is a taproot — a single root that goes down through three layers, with the deepest layer drawing water from the others. Knowledge moves down the taproot; nothing moves back up. Each layer is owned by exactly one writer.

rung 1 FIN Central — universal knowledge commodities · varieties · vendors · regions · FSMA rules written by the Central renderer Worker · scheduled every 15 min rung 2 Push-based sync transport GitHub workflow_dispatch · 488 MDs mirrored in < 5 min rung 3 Tenant overlay (nathel-intranet) operational events + Central MDs → fused documents today's arrivals · QC findings · sales situation · vendor scorecards written by tenant projector Workers · event-driven + cron read by everyone audit-trail tenant-private to humans to agents to compliance

Animated dashes show the flow. Central writes once. The mirror copies. The tenant composes. No layer writes upward.

Why three rungs, not one?

Rung 1 — Central

Identical across tenants

Universal produce knowledge must be the same for everyone. FDA / FSMA contract says the commodity profile FIN cites for blackberry can't be different at Nathel than at any future tenant. Centralization protects this.

Rung 2 — Transport

Auditable and replayable

Every Central update becomes a git commit on the tenant's repo. The full sync history is a queryable timeline. If Central changes a commodity's defect class taxonomy, every tenant's mirror commit records the moment they received it.

Rung 3 — Tenant

Sovereign and overlaid

Nathel's vendor relationships, customer prices, cost basis, and operational intel never leave Nathel's database. The tenant composes Central knowledge with its own data — but writes only to its own paths.

Together

A working brain

Collapse any two rungs and you lose one of the three contracts. The system is minimal but not less. Three rungs is the smallest number that preserves universality + sovereignty + auditability at the same time.

The format

Markdown.
Just markdown.

Every document in the FIN intranet is a markdown file — the same kind of file you'd write a README in. A human can open it in any text editor. The agent reads the same bytes. The format is deliberately humble: YAML frontmatter on top, body below. The cleverness is in what's in the frontmatter.

Below: a real Central commodity profile, shown two ways. Click the toggle.

fin-central-intranet:docs/entity_profiles/commodities/blackberry.md
---
schema_version: 1
doc_id: commodity_profile_blackberry
doc_kind: entity_profile
title: Blackberry — Commodity Profile
slug: commodity-profile-blackberry
data_plane: universal_intelligence
visibility: public_anonymized
linked_entities:
  - { type: variety, slug: navaho }
  - { type: variety, slug: triple_crown }
  - { type: region, slug: oregon }
  - { type: region, slug: mexico_central }
tags: [commodity, berries, soft_fruit, plane_3]
---

# Blackberry — Commodity Profile

Blackberries are a perishable soft-fruit commodity with high market
sensitivity. They are typically packed in 6-oz, 12-oz, and 18-oz
clamshells. Color is matte black; gloss indicates over-ripeness.

## Post-harvest physiology

Optimal storage: 32–34°F (0–1°C) at 90–95% relative humidity.
Shelf life: 3–6 days under optimal conditions; reduced to
24–48 hours when temperature has been violated by ≥4°F at any
point in the chain.

## Common defects

- Leaky berries: cell-wall breakdown, typically caused by
  rough handling or post-harvest temperature shock.
- Mold (Botrytis cinerea): gray fuzzy growth at calyx,
  indicates extended storage above 38°F or condensation in clamshell.
- Reversion (red drupelets): a few drupes turn red under
  light stress; cosmetic, not a quality failure unless > 15% per clamshell.

## Varieties of note

The [[variety:navaho]] cultivar is thornless, firm, dominant in
Oregon production. [[variety:triple_crown]] is more delicate but
flavor-superior; primarily mid-Atlantic.

# ...sections continue: Growing regions, Seasonal windows, FSMA notes,
# Vendor history, Cited recalls, Linked operational signals
identity
doc_id
commodity_profile_blackberry
doc_kind
entity_profile
data_plane
universal_intelligence
visibility
public_anonymized
linked entities — what the agent can drill into
drill targets
variety / navaho variety / triple_crown region / oregon region / mexico_central
extracted claims — what becomes citable
claim · storage
optimal 32–34°F at 90–95% RH cited from this doc
claim · shelf life
3–6 days optimal, 24–48 hrs after temp violation cited from this doc
defect class
leaky berries · mold · reversion
cultivar dominance
navaho → Oregon · triple_crown → mid-Atlantic
wikilinks resolved — the graph it joins
→ variety_profile_navaho
live in Central
→ variety_profile_triple_crown
live in Central
→ region_oregon
live in Central
tenant overlay — what Nathel adds when fused
recent arrivals
lot 547701 · Malena Produce · 5 days agolot 548591 · Driscoll's · 2 days ago
vendor relationships
Malena ProduceOzBluCarb America
price signals (7d)
Hunts Point: $32–36 / 6-oz flGM read: "blues started to work"
Notice what just happened. The same file produced two views. In the human view, it reads like a refined trade publication. In the agent view, the structure becomes graph-shaped: identity, drill targets, citable claims, the wikilinks that join it to the rest of the knowledge graph, and — only when this document is served for Nathel — the tenant overlay of operational reality on top.

The frontmatter is the contract

Four frontmatter fields carry most of the system's intelligence:

  • doc_kind tells the renderer how to format it and which template (entity profile? event digest? proof package?).
  • data_plane tells the security layer whether this is universal knowledge, tenant operational data, or private workspace — controlling who can see it and whether it federates.
  • linked_entities tells the graph builder what to connect this document to. Every entity listed becomes a click-through backlink, automatically.
  • source_attribution tells the provenance layer where every claim came from. Federal recall investigators read this field first.
a tenant overlay document
---
doc_id: nathel_daily_sales_2026_05_18
doc_kind: event_digest
data_plane: relationship_data
visibility: company
source_attribution:
  - producer: daily_sales_situation
  - source_events:
    - evt_5ab9c4
    - evt_5abd02
    - evt_5acd1f
linked_entities:
  - { type: commodity, slug: blackberry }
  - { type: vendor, slug: malena_produce }
  - { type: customer, slug: whole_foods_ne }
---

# Daily Sales Situation — May 18, 2026

## Yesterday's snapshot

312 cases of blackberry sold across 8 customers.
Average fill rate: 94% (up 3pp from prior week).

## Attention list

- Whole Foods NE: typical Tuesday order missing. Last week
  ordered 52 cases. Suggested: call the buyer.
- Restaurant Depot: 18-case rejection on lot 548591
  (calyx mold). Linked to QC inspection.
The fusion lens

One question.
Three answers.

An agent asks: "Tell me about blackberry." The answer depends on which lens the system serves. Use the tabs below to see all three.

What anyone can see

The universal knowledge layer. The same answer everyone gets, today and a year from now. Cited, deterministic, public.

Blackberry — Commodity Profile A perishable soft-fruit commodity. Optimal storage: 32–34°F at 90–95% RH. Shelf life: 3–6 days optimal. Notable varieties: navaho, triple_crown. Common defects: leaky, mold, reversion. Major regions: Oregon, Mexico (Central), California (Salinas). Citations: FDA Cold Chain Spec · USDA AMS Cooperative Extension · Driscoll's research

What only Nathel can see

Operational reality. Today's lots, vendor relationships, cost basis, customer patterns. Never leaves Nathel's database.

Blackberry — Nathel operational view Last 5 lots received: - 548591 · Driscoll's · 2026-05-16 · 312 cs · QC pass - 548547 · Malena Produce · 2026-05-14 · 144 cs · 1 fail - 548421 · OzBlu · 2026-05-12 · 180 cs · QC pass Active customers (last 30d): 14 buyers, mix of foodservice + retail Top 3 by volume: Whole Foods NE · Restaurant Depot · Baldor GM read (yesterday): "Blues started to work this week. Shippers looking for $40 FOB. Mexico still going." Cost basis (avg, 30d): $24.18/case Margin band: 12–18%

What the agent actually reads

When the agent asks about blackberry while serving Nathel, both layers are composed into a single document. Universal knowledge on top, operational overlay beneath, all wikilinks resolved.

Blackberry — Composed Profile (for nathel) ## Universal knowledge Optimal storage: 32–34°F at 90–95% RH. Shelf life: 3–6 days optimal. Varieties: → [[variety:navaho]] · [[variety:triple_crown]] ## Nathel operational overlay In inventory now: 312 cs · lot 548591 (Driscoll's · arrived 32.4°F · QC pass · clean) In-flight POs: 2 (Malena, OzBlu — ETA 5/19) Customer signal: Whole Foods NE typical Tuesday order has not arrived this week. ## Recent vendor incidents lot 547701 (Malena, 2 weeks ago): 3 pallets shifted/restacked, 31 cases damaged → vendor scorecard noted, no margin variance triggered — claims cite events evt_5ab9c4..evt_5acd1f —
Why it matters

A document that
everyone can read.

Each person in a produce business asks different questions. Each gets the same kind of answer: a cited document, the agent can drill into, that links to live operational truth.

Warehouse worker

"Show me the photo Glenn took on lot 548591."

The agent answers with the photo, the inspector's narrative, what defect class it falls under, and what the universal commodity profile says about it.

"It just knows. I don't have to remember which folder."
Buyer

"What's the read on Mexico blackberry next week?"

Hunts Point pricing, the GM's Sunday Night Update, in-flight POs, Central's regional pattern for May — all composed into one brief. Cited.

"It saves me the call to seven people."
Sales

"Has Whole Foods NE ordered their typical Tuesday?"

The customer × commodity matrix surfaces the missing order. The agent suggests the outreach. The relevant context — recent pricing, available lots — is attached.

"It tells me who to call before they call me."
QC inspector

"Compare this lot's calyx mold to vendor history."

QC history per vendor per commodity, the universal defect taxonomy, the photo evidence chain — all composed into a structured assessment.

"My inspection is a document, not just a checkbox."
Compliance officer

"Trace lot 548591 through to every customer."

A deterministic recall-trace document. Every claim cites an event. Re-renderable six months later with byte-identical output. FSMA 204 ready.

"It's the audit binder, but actually accurate."
The agent

"What do I cite when I answer this?"

Every document has frontmatter declaring its claims' provenance. The agent doesn't hallucinate — it can show its work, back to the event.

"I have a real knowledge base, not a chat history."
"The first time the warehouse foreman asked the agent a question and got back a cited answer — with the photo, with the narrative, with the vendor history — was the first time everyone in the room agreed the AI wasn't a toy." internal note · Nathel pilot, May 2026
The novelty

An enterprise OS
built for agents.

Most enterprise software was built on the assumption that the user is human and the data is private. The interface was the form. The interface was the report. The data sat in tables only the application knew how to reach.

FIN flips that assumption. The data is a document. The interface is the document. The agent reads the same document the human reads. And the document itself carries enough metadata — provenance, links, audience, plane — that the agent doesn't need a separate API to understand it. The document is the API.

This isn't documentation about the system. This is the system.


Five things you can't find together anywhere else

Novelty 01

The intranet is the brain

Not a documentation site about the system — the actual artifact the system reasons over. Every event, every projection, every signal lands as a markdown row the agent can cite.

Novelty 02

Universal + sovereign in one query

The same agent question composes industry-wide produce knowledge with this tenant's private operational reality. The fusion happens at the document layer, not at the API boundary.

Novelty 03

Federal-grade provenance, free

Every claim carries its event sources in the frontmatter. Re-rendering a recall trace six months later produces byte-identical output. The audit binder is the same artifact the inspector reads on Tuesday.

Novelty 04

Cross-ERP fungibility

A produce distributor running on Produce Pro can become a FIN tenant in weeks. The same shape works for Famous Software, Sage X3, NetSuite. The ERP becomes an adapter pack — not a rewrite.

Novelty 05

Mobile-first, agent-first

The warehouse worker on a phone, the AI agent in a server room, the federal investigator on a laptop — all reading the same documents. No separate "AI tier" that diverges from what the humans see.

The principle

"If a senior produce expert can read it like a trade publication, an agent can reason like one."

This is the design principle. Everything in FIN's intranet follows from it.

Frequently asked

Things people
ask the team.

Is this just a wiki with extra steps?
A wiki is for humans to write and humans to read. FIN's intranet is generated and read by both humans and agents, with structured metadata that makes every claim citable. The format is markdown because markdown is the lowest-friction format that humans, AIs, version control, and search can all use natively. The system isn't the wiki — the system is the projector layer that writes the documents from event-sourced operational reality.
Why GitHub repositories for an intranet?
Three reasons. First, version control gives a full immutable history — every change is an audit-traceable commit. Second, the GitHub workflow infrastructure gives us the rung-2 sync transport for free. Third, the same engineers who build the FIN system can use their existing tools to inspect the intranet. The repository is implementation detail — readers see clean markdown rendered to web pages.
What stops Central knowledge from leaking tenant data — or vice versa?
The three-rung architecture itself. Rung 1 (Central) only writes to Central paths. Rung 2 (transport) only writes to _taproot_mirror/ on the tenant. Rung 3 (tenant) only writes to tenant paths. No layer writes upward. The data_plane field in every document's frontmatter enforces this at the security boundary. The tenant's customer prices, cost basis, and vendor relationships are structurally incapable of reaching Central.
How is this different from what NetSuite / SAP / etc. offer?
Traditional ERPs are databases with screens on top. The "knowledge" lives in relational rows that only the application can interpret. To get an agent to use that data, you have to expose it through APIs the agent learns to call. FIN inverts this: the documents are the data the agent reads. The ERP's operational tables still exist, but they exist as event-sourced facts that produce documents. The agent doesn't navigate forms. The agent reads pages, the way a senior expert reads trade publications.
What happens when Central's knowledge changes?
A scheduled renderer worker on FIN Central detects the change and re-renders the affected commodity / variety / vendor / region MD. That commit triggers the rung-2 sync, which pushes to every tenant within five minutes. Each tenant's mirror commit records the moment the new version arrived. If the change affects a tenant-overlay document, the tenant projector re-renders downstream — but historical proof packages and recall traces stay frozen against the Central version they were rendered with. Determinism preserved.
What if a tenant wants something Central doesn't have?
The tenant overlay can declare anything Central hasn't covered. If Central doesn't have a profile for a niche commodity (say, mountain laurel berries), the tenant's commodity reference still works — it just renders with a central_pending flag and the tenant overlay carries the full content until Central catches up. The system gracefully degrades; it never blocks.
Who owns the rights to the universal knowledge layer?
The universal layer is built from public-domain sources (USDA, FDA, FSMA), authoritative trade references that FIN holds licenses for, and aggregated anonymized signal from tenants. The aggregated portion is governed by an explicit anonymization policy and a contributor agreement. Tenants who contribute receive credit; tenant-private operational data never federates upward.