Flow
ServicesIntelligence Service

Company model

The three-layer model of Flow that intelligence compiles into — identity, strategy, dated operating facts, and the terrain of named metrics and rollups — seeded from the 2026-09-11 business model.

The Company model: The structured three-layer model of Flow that the knowledge layer compiles into: identity (human-owned), strategy (proposed then confirmed), and operating facts (automatic, each with an as-of date). Nothing is deleted; a change is superseded. Distinct from a company fact, which is the admin-written source text a claim can be derived from. is the compile target for Company Brain. Workspace holds the conversations, notes, Slack, and meetings. Intelligence already turns those into quote-backed claims. This domain is what those claims, and later the insight harness, are scored against: what Flow is, what it is trying to win, and what is true now.

It is a domain inside intelligence, not a third service. Raw evidence still lives in workspace. Company fact: A statement about the business that a platform admin has decided is settled — a legal entity name, what a product is, which market the company sells into. It is a record in workspace's fact domain, written as markdown or uploaded as a file, readable by anyone and writable only by a platform admin. Intelligence derives claims from it the ordinary way and then confirms them instead of queueing them for review, and those claims go into every project's context pack. Distinct from an insight whose kind happens to be `fact`, which is any claim the pipeline extracted from a conversation and which still goes to a reviewer. remain the admin-written source text; the model is the structured, versioned form of the same identity and strategy, plus dated operating measurements.

services/intelligence/migrations/0040_portfolio.sql services/intelligence/migrations/0041_portfolio_terrain.sql services/intelligence/migrations/0042_portfolio_snowflake.sql services/intelligence/migrations/0043_portfolio_harness.sql services/intelligence/migrations/0044_portfolio_brief.sql services/intelligence/migrations/0045_portfolio_memo.sql services/intelligence/migrations/0046_portfolio_memo_thesis.sql

Three layers

LayerWhat it holdsWho writes it
IdentityWhat Flow is and will not trade awayA person confirms; never a job
StrategyCurrent bets, the accepted tradeoff, two equal priorities, open forksThe system may propose; a person confirms
OperatingProperties, pipeline, workstreams, recent decisionsAutomatic, each figure carrying an as-of date

Nothing is deleted. A changed entry is marked superseded with the date, the reason, and what replaced it. Recency does not decide weight. The layer rule does.

Incoming evidence is typed before it may touch the model: fact, correction, decision, reversal, measurement, or norm. A measurement cannot write identity. A norm does not promote itself.

Unit role

Every property is owned, jv, managed, sold, or unresolved. Only managed units count toward the third-party management bet (Unit role: Whether a property is owned, a joint venture, managed for a third-party owner, sold, or unresolved. Only managed units count toward the third-party management bet. Owned and JV growth must not be scored as that scale.). Owned and JV growth must not look like that scale. Planned MENA openings whose role is not on file are unresolved until someone settles them — they are not guessed.

GET /v1/portfolio/model reports bet1_managed_units as that managed total and units_by_role for the rest.

Buildings and deals

Buildings and deals are entity kinds, seeded from the same portfolio, with aliases so a Slack "Watermarc" or "The Fay" resolves to the operating row. They appear on the ordinary graph endpoints.

Terrain

compile_portfolio_terrain (nightly, on the batch worker) copies operating numbers into Named metric: A closed set of operating numbers the insight harness may ask for by slug: occupancy, leased percent, units, Bet 1 managed units, vacant units, vacant rent, asking rent, marketing spend, and the audience and hospitality counts. The agent never writes SQL. Adding a metric is a migration. — occupancy, leased percent, units, Bet 1 managed units, vacant units, vacant rent, asking rent, marketing spend, leases, and the audience and hospitality counts — and scores each property against peers of the same Unit role: Whether a property is owned, a joint venture, managed for a third-party owner, sold, or unresolved. Only managed units count toward the third-party management bet. Owned and JV growth must not be scored as that scale.. Olaya is the only managed property in the seed, so it has no z-score.

ingest_portfolio_snowflake runs first. It copies occupancy history, unit counts, vacant-unit dollars, marketing spend, prospect counts, email lists, and hospitality POS counts from Snowflake (ANALYTICS) onto those metrics, source=snowflake. Audience segments and email lists land on their own tables (counts only; no person keys or addresses). The compile job then leaves a warehouse number in place even when the seed has a later as-of date. Unmapped warehouse buildings are skipped. Leased percent is still the seed: the warehouse column that looks like it is not the same measure.

When Snowflake credentials are unset, ingest skips and terrain is the seed.

It then scans published claims for building, deal, vendor, and team names (longest alias first, so "Flow Fort Lauderdale" is one mention) and writes:

  • weekly and monthly rollups: insight / decision / fact / question counts, plus the claim titles joined together
  • attention share: what fraction of that week's published claims named this entity
  • a decision log: operating-layer decision statements and published decision claims, attached to an entity when the text names one. Follow-through is unknown until a later slice can see tickets or metric movement.

Empty until the job has run.

Insight harness

run_portfolio_harness (nightly, after terrain, on the batch worker) is the insight loop. It surveys commercial deviations on the compiled terrain — vacant rent, spend, owned audience, hospitality capture, a price ladder — and baseline-generated questions on every per-building named metric: occupancy, leased percent, vacant rent, asking rent, marketing spend, leases, down-unit rent, prospects, and toured-never-leased, each against peer z and own history. Attention share versus vacant rent still runs. The commercial theses stay as a check; they are not the only questions.

It checks insight memory, then kills data artifacts: as-of dates more than 60 days apart, a missing occupancy percent when vacant units or vacant rent are already on file, a story the company model already names (lease-up, sell-out, listed for sale, seller figure), “follow-through unknown,” a fingerprint already killed or human-rejected, a fingerprint raised in the last 14 days, and own-history that matches the same calendar month a year earlier within 1σ. If there is no prior-year observation, the falsification note says so; it does not invent one. Slack silence is evidence that a commercial problem is unworked; it is not a second source.

It investigates a diverse slice (at most one management-deals finding, at most two per other family, up to twelve) and keeps the ones that meet the output contract: a Named metric: A closed set of operating numbers the insight harness may ask for by slug: occupancy, leased percent, units, Bet 1 managed units, vacant units, vacant rent, asking rent, marketing spend, and the audience and hospitality counts. The agent never writes SQL. Adding a metric is a migration., materiality in dollars or people, canonical entities, a deviation statement, at least two sources joined, evidence pointers, a falsification note, novelty from insight memory, and a decision it would change. After a hypothesis exists, drilldown may try to kill it. Drilldown is verify-only: permission-filtered workspace snippets and provenance refs. Raw Slack is not copied into the finding body. A candidate whose only second source would be drilldown is dropped. The loop is mechanical. It does not call a language model in investigate. The company-model seed is how a finding is mapped to a decision; it does not count as a second source.

Every candidate, including kills, is written to insight memory. Novelty on a kept finding is that check, not a stub.

Findings that survive are clustered into Portfolio brief: A company-altitude story clustered from building-level findings: a thesis, a material number, a recommendation, and where the story could be wrong. Shadow only; not published as an insight.: a few company-altitude stories with a thesis, a number, a recommendation with an owner, and where the story could be wrong. Occupancy-bookkeeping themes do not lead. Building-level findings stay underneath as evidence.

compile_portfolio_memo (nightly, after the harness) writes one executive memo from those surviving briefs. It does not survey a parallel thesis list. A configured language model may pick among survivor slugs and polish the prose; a stub ranks by materiality and skips last night's slug when another survivor exists. If nothing survived, there is no memo. The numbers are mechanical either way. The memo is the Findings-tab lead: a thesis, a people or dollar figure, tables, a recommendation with owners, a specific objection, and one unresolved question.

compile_portfolio_weekly_brief (nightly, after the memo) records reviewer precision for the ISO week. It copies at most five accepted findings into a weekly brief only when the last three completed weeks each have precision of 80% or higher and at least five reviews. Until that gate opens it logs a skip and writes nothing. The Findings tab shows the precision counter; it does not lead with a weekly brief.

Findings are written as Portfolio finding: A harness-produced claim about the company model. It must name a metric, join at least two sources, state a deviation from a baseline, and name a decision it would change. Shadow findings are for review and are not published as insights. The harness clusters them into portfolio briefs. in shadow status. A reviewer sees the briefs on the Findings tab and can accept or reject the supporting findings, with optional free-text feedback stored on the memory row. Accepting sets outcome to acknowledged and suppresses the same fingerprint until a reviewer clears it or the materiality band changes. Accepting one does not publish it as an insight.

The ten tools are also HTTP reads under /v1/portfolio/tools/… so a later agent or MCP wrapper can call the same functions. Tool 9 is drilldown. Tool 10 is insight memory, used by the harness.

Read it

SurfacePath
APIGET /v1/portfolio/model, GET /v1/portfolio/terrain, GET /v1/portfolio/findings, GET /v1/portfolio/tools/…
Review app/intelligence/company-model (Terrain, Findings, and Usage are tabs). Usage is GET /v1/conversations/usage on workspace, not the compiled model; platform admins only

On this page