Company brain

Approved Oct 3 night: notes store (proven at Willows with an end-to-end test), email intake (removed 2026-11-03, Fede), and meeting transcripts → notes. Building overnight. Nothing turns on at Western Slope until Fede says so.

Fede, 2026-10-03: "the whole point of this program is to actually deploy it in that customer… renewals… capture the notes in their company brain… nothing will be shown to prospects… make a plan first."

Goal: Western Slope's meeting notes land in their Internal brain, staff can ask Clara about them, and renewals use them. Prospects and residents never see any of it.

Two tracks

Track B phases

How the renewal engine evolves

Today it's all fixed rules, no AI on the money: renewal switches, a 90-day window, eligibility (balance over 2 months of rent or more than 2 late payments → a person), gates (declined, notice given, opted out, transfer, signer email), rent strategy (market, current + %, current + $), terms and month-to-month fee, Supervised mode. The rent is frozen on the renewal and the AppFolio robot writes that number. Nobody can override rent on a single lease today — that per-lease override is the one new piece.

When a note and a rule disagree: gates win (a declined or noticed tenant is never offered), then the meeting note, then building policy, then company policy. A note that asks for rent below current, or that can't be matched to one lease, goes to a person.

Proof of concept: Camellia renewals with and without notes (Oct 3 night)

We ran today's renewal engine on Camellia's 27 leases ending Jul 31 – Sep 30. Then we ran it again with notes pulled from five team meetings where the property manager went through renewals lease by lease. Both runs were graded against what actually happened. Local test only, nothing merged, nothing written to production.

What it means: notes barely move the final outcome. The real gain is in how leases get handled. A lease going to a lawyer is held, a tenant moving out isn't chased, and a paper renewal isn't texted and auto-switched to month-to-month. One note made things worse: a casual "he'll just go month to month" was read as a decision, and that tenant renewed.

Where it breaks:

1. No way to change one lease's offer once it's sent. Rent and term are locked at that point. Clara's text offer also recomputes rent and assumes 12 months, so a note-based change would be ignored there.
2. No "paper renewal" state. The engine keeps texting, then switches the tenant to month-to-month at +$100.
3. About 1 in 6 notes (19 of 119) couldn't be tied to one lease. Causes: group statements, shared first names, and offhand remarks. A name cross-check stopped one wrong match.

Eight labeled synthetic notes (wrong unit, conflicting rent, below-current rent, a note against a notice to vacate) were all handled by the rules. One rule changed during the run: a notice to vacate always beats a meeting note.

Fixes that ship regardless

• Clara's text-offer quotes a recomputed rent (ignores policy, hard-codes 12 months) instead of the frozen number, in three places. A correctness fix, no switch; needed before notes touch rent.
• Video end-of-call drops the transcript when the end event arrives first. Needed before meeting join can make notes.

Decisions (Fede, Oct 3 night)

1. Where notes go: clara@propflowai.co; the company comes from the sender's domain.
2. Auto-applying notes to renewals: no — not building an auto-apply step.
3. Order: email first, then meeting transcripts.
4. Western Slope renewal policy: a company setting; set it, don't ask.
5. The knowledge base is Public (2026-10-07, Fede): private information (personal phone numbers, emails, anything a staff member marks do-not-share) is never saved there, and a staff-only label on a shared row is not separation. The knowledge writer now refuses such items in code (branch fede/kb-no-private-info). This answers the open question “does a staff answer become public knowledge, an internal-only item, or get classified per answer?”: an answer saves only if it is Public; otherwise it is not saved.

Sources: renewal engine and intake paths read from the propflowai repo on 2026-10-03 (renewal-auto-start.ts, renewal-rent.ts, eligibility/engine.ts, process-inbound-email.ts, calls/ended/handler.ts); Western Slope renewals state from the 09-28 renewals page.

Context only, no decision yet

What exists, what Fede has said, and what is open, before any design for where Clara stores what she learns from staff replies.

Fede's words, newest first

Where he changed his mind

• Company brain. A design on Oct 2, then a pilot approved on Oct 3.
• Saving an answer. No gate, then a confirmation prompt, then save immediately and tell the staffer in the same thread.
• Which rule wins. Portfolio wins, then property wins on a title match, then newest at the narrowest scope wins.
• Knowledge shape. Fixed fields, then split into facts, then free-form text with structure chosen later, now doubt that paragraphs scale.

Two lanes today, only one saves

Western Slope runs on the autonomous lane, so its staff answers (including the six-month-lease case) take the path that does not save today.

What's built

• Storage is typed fields plus free-form paragraphs on the same record.
• Read path. The whole knowledge block is injected on every turn — there is no retrieval step that pulls just the relevant piece.
• Real staff have never closed the loop. 0 of 26 cases in one test and 0 of 16 in another were answered by a real staff member; Western Slope staff is the example — only Fede's own test answers were ever saved.

Five open conflicts

• Four different rules exist for which scope wins when rules disagree, never reconciled into one.
• Whether a taught answer applies to one property or the whole company is unresolved — one path defaults to property-only, another to company-wide.
• Where an internal-only (staff-facing) answer should live is unresolved — one proposal tags it inside the public store, another design says a label on a shared row is not enough separation.
• Earlier plans for a human review queue on a taught answer are overtaken by the standing rule against manual-decision UI for routine data work.
• One design page's description of how the save is written does not match what the code actually writes.

Ten open questions

1. Does a staff answer become public knowledge, an internal-only item, or get classified per answer? Answered 2026-10-07: saves only if Public; see the Oct 7 decision above.
2. If something starts internal-only, how does it ever become public?
3. Is the default scope company-wide or property-only, and who decides that?
4. Which precedence rule applies when scopes disagree?
5. Is a time-bound answer (tied to a running promotion) knowledge with an expiry, a concession, or a one-off that shouldn't be saved as policy at all?
6. Should answers stay as paragraphs, or become atomic items with their own validity period?
7. When an answer is corrected later, does the new answer replace the old one or do both stay on record?
8. Does today's knowledge read path work as-is with whatever is decided here, or does it need to change too?
9. Is building the save for the autonomous lane a fix (ships for everyone, no switch) or a new capability (ships default-off until a customer is turned on)?
10. What counts as proof this works: a simulated test, or a real staff reply at a live customer?

One shape for every item

• Pages per entity, copied from GBrain. Each tenant, unit, lease, property and company gets a short current summary on top of an append-only, cited timeline of items. GBrain calls these "compiled truth" over "timeline" (GBrain schema).
• Facts that change carry valid-from and valid-until, the way Graphiti stores them (Graphiti).
• Knowledge stays apart from procedures. Items are knowledge; what a workflow may do with them (its effect list) is procedure. Intercom Fin (Guidance, Procedures), Decagon (agent operating procedures) and Maven (Charters) all split them this way (Intercom, Decagon, Maven).
• Only items with an effect drive actions. A decision is an item with an effect. A signal is an item computed by a job. A judgment ("disputes every charge") is an Internal item like any other: in v1 every staff member sees every Internal item.

Every kind of company information, one table

• Not a migration. The item shape is a contract. Today's stores (company knowledge sections, AppFolio sync tables, renewal rules) are read through it as they are. New sources write to it natively. Zero rows move.
• Who wins, for every consumer: law and safety rails, then the newest item at the narrowest scope (person, lease, unit, property, company), then defaults. It extends the knowledge base's existing "the building wins over the company" rule.

Fede: "it is a very different mental model from the knowledge base that's meant to be public facing." And for v1: "Start with only two levels… Everything is internal, to simplify, because there's no privacy right now in the system, so everyone should see all the conversations." The two words are the ones shipped products use (research).

Private is reserved, not built. The audience field has room for a third value, Private (one teammate only, as in Notion, Claude Projects and Help Scout). Nothing writes it until a customer asks for it.

Invented example: Maria texts Clara "Unit 9 is on a payment plan" or forwards meeting notes; both land as Internal and every teammate's Clara sees them. "Pet deposit is $400 everywhere now" reaches prospects only once someone publishes it to Knowledge & policies; the quote stays Internal.

Also proposed: Clara reads the notes managers already keep on each property and home record, on the same 6-hour pull. Numbers and decisions: onboarding playbook, section 4b.

From evidence to items

1. Store raw. As received, with speakers and timestamps. Never edited.
2. Extract. A model reads the whole thing and writes items, each with a verbatim quote. Questions, what-ifs and brainstorming are skipped.
3. Match the scope. "Twelve", "the Garcias", "Pine Court" are matched against that company's own leases, people and buildings only. No match, or more than one: the item is kept unmatched and never drives an action.
4. Live at once, no approval queue (Fede, 2026-09-08). After a meeting Clara sends attendees a short "here's what I took away" note. Anyone corrects it by replying in plain words; Clara replaces the item. Silence means it stands.
5. Re-runnable. The extractor is versioned; re-running it on the evidence rebuilds the items.

Fede: "We serve small and medium businesses that already have their tools: Notion, Monday, Google Drive/Docs, Microsoft SharePoint/OneDrive… Connectors feed data into the company brain at the right privacy level." A connector is one more source in the framework above: it writes items, stamped with where they came from and an audience.

How others present connectors

Common pattern: an admin connects a tool once for the whole company; most products sync and index, while MCP-based ones read live; the customer-facing bot only sees sources an admin marks for it. Sierra and Decagon document "integrations" but not their permission model (unverified). Our app already has Settings → Connections (AppFolio today); outside tools go on that same page.

Open-source frameworks we could build on

Recommendation: Airbyte's open-source connectors, run in our AWS, for sync. MCP later for live lookups. They are the only option that covers all five tools Fede named under an open license, run entirely on our infrastructure, and already sync Google Drive permissions, which a future Private level could use. Nango is TypeScript, but self-hosted syncs need its paid plan, so we would still write every sync. Onyx lacks Monday and charges for permission sync. We run the connectors as containers from a Temporal job, not the whole Airbyte platform, and translate their output into items. That last step is ours to write.

Two modes

• Sync (first): a scheduled job copies what an admin points it at (a Notion teamspace, a Drive folder, a SharePoint site) into evidence and items. Fast to read, works when the tool is down, and the planted-leak test covers it.
• Live lookup (later): a staff-only tool calls the tool's MCP server at question time, for things too big or fast-changing to copy. It sits behind the same staff check as get_internal_context.

Each connection belongs to one company, under its org node, like lines, calendars and mailboxes in Gera's model. Turning a connector on at a customer is a new capability: a company setting, off by default, that Fede turns on.

The wall is structural, not a prompt instruction. Three layers, each enough on its own to stop a leak.

• Shapes, never quoted. Workflows read Internal and write a typed effect, such as an offer at +3%. The renewal letter, text and call script have no reason field, so the note cannot reach the tenant even by mistake. The reason is absent, not hidden.
• Derived things inherit the audience. Summaries, counts and links built from Internal items are Internal. GBrain's private filter once leaked through graph links and backlink counts, not page text (fix), and its remember command defaulted to shared regardless of settings (issue).
• A planted-leak test. Plant a unique Internal sentence, replay tenant and prospect conversations, expect it nowhere. A check is only trusted once it goes red on a planted violation.
• Access: every staff member of that company sees every Internal item in v1 (Fede: "everyone should see all the conversations"). Property owners are not staff, so owner access needs its own grant (section 7).

Where the wall sits in today's code

Read from propflowai origin/main at 6ed1cbe8cf, 2026-10-02. Fede thought role-gated staff tools already exist: they do.

Anthropic's guidance: "If your knowledge base is smaller than 200,000 tokens (about 500 pages of material), you can just include the entire knowledge base in the prompt" (Anthropic). Cached prompt reads cost a tenth of normal input (prompt caching). A company's Public knowledge is roughly 10k tokens (our estimate), so it stays in the prompt.

On a live call, free-text search stays off the critical path: the caller's own facts load at call start, as video Clara's snapshot already does (our inference, not a cited figure).

Checked against Gera's design. No conflict, with one gap.

• The company is the wall. Every item and its evidence live under the company's org node; scope links point only to its own properties, units, leases and people. GBrain draws the same line: "if the data owner changes, it's a brain boundary" (GBrain).
• Scope uses his nodes, and "newest at the narrowest scope wins" is the same chain walk as his resolver.
• Roles: a staff job is an org-level role with an optional building subset. Internal follows that subset.
• Gap: owner visibility. A property owner is a relationship row with no rung in the role ladder, so owner-visible items need a new grant key, default off.
• Connectors attach at the org, like lines, calendars and mailboxes in his model; a connector's items land only under that company.
• PMS credential holder (Property.ownerId) grants no read access. Matches.

Web research, 2026-10-02, two passes. Vendor docs linked inline; anything not confirmed from a primary page is marked unverified.

Public vs Internal: the customer-service products

Same pattern everywhere: one library, an audience on each item, and the customer-facing AI limited to the public audience. Nobody says "staff only"; they say "internal".

Private vs shared: one person's memory vs the team's

Kept for when Private is built. v1 has no Private level.

GBrain (Garry Tan's open-source brain)

One database per data owner, holding typed pages (person, company, meeting, email, deal and more). Each page has a rewritable "compiled truth" over an append-only timeline where "every claim cites its source". Pages and facts are world or private; remote agents get read, write or admin scopes; derived pages are treated as private by default (issue). Its people pages include an "Assessment" section, the same kind of staff judgment we keep Internal (schema). Young (April 2026), single author, active leak fixes.

Meetings, property management, consumer memory

• New meeting notes are private by default at Notion, Glean, Granola and Fathom; Microsoft shares recaps with invitees; Slack huddle notes go to the channel (Notion, Glean, Fathom, Microsoft). We default meetings Clara is given to Internal instead, because a customer forwards them to Clara precisely so the team's assistant knows.
• No property-management vendor documents a wall between staff notes and the resident-facing AI. AppFolio Realm-X (2026-09-29) has a per-user "Memory" and a "Knowledge Base" under "customer-set permissions"; any staff/resident split is unverified (announcement). EliseAI's "Knowledge" is what its AI tells prospects and residents; renewals start when the PMS marks one Approved (docs, docs). Entrata using staff notes in renewals: unverified.
• Consumer memory is single-person. Dot shut down on 2025-10-05 (TechCrunch). Meta's Muse agent (announced 2026-09-08) learns one person's memory, which they can edit, tell it to forget, or import; no "brain" feature was found (Meta, help). Grok's per-memory "Forget" is reported secondhand only (unverified).
• Every product lets people see, edit and forget their memory (ChatGPT "Manage memories", Claude "Memory summary", Muse "Forget"). We copy that screen.

Patterns we copy

1. An audience on every item, with the customer-facing AI restricted to Public (Intercom, Zendesk, Salesforce).
2. Physically separate stores for the hard wall; filters only as a second layer (AWS, Pinecone).
3. An independent check at the send layer (the 2026 Copilot bug).
4. Shared only through a named shared place, never by automatic promotion (ChatGPT, Claude, Notion, Copilot, Dust). For us that is publishing Internal to Public; per-person Private waits until a customer asks.
5. Inbound content is untrusted: one email with hidden instructions pulled Microsoft 365 Copilot data out with no click (EchoLeak, CVE-2025-32711). Only verified staff write Internal items, and items are data, never instructions.
6. Decisions get their own record apart from the transcript. Competitors keep only transcripts and summaries, and their renewal decisions live in the PMS: that gap is our renewals example.

Rent recommendations: RealPage's rent-pricing settlement (Federal Register, 2026-01-21) makes pooled rent advice sensitive. Here every increase comes from that client's own team, and the per-company wall means one client's decisions never inform another's rent.

Recommendation: copy patterns; adopt no framework now. None gives an audience wall or hard per-company isolation; most are Python, while we run TypeScript on DynamoDB, S3 and Temporal; and Zep needs its own cloud, so customer data would leave our infrastructure.

Letta, Cognee, Supermemory, Basic Memory and Memori were also reviewed; none adds an audience wall. Letta's details are unverified.

Static mockups, modeled on the app's real Settings screens and labels. The chips copy Intercom's internal-vs-public audience. People see and edit what Clara knows; there is nothing to approve (Fede, 2026-09-08: the engine decides, humans fix the engine).

A. Settings: one place per audience

"Knowledge & policies", "Connections", the subtitle and the menu order are today's real ones.

B. Internal, company view: every source in one list

C. A tenant's page: the Internal panel and one item

The panel's summary line over the item list is GBrain's compiled truth over its timeline. Today's AppFolio note row in conversations says "Only your team sees this; Clara never does." Under this design staff-facing Clara does read it, so that line becomes the Internal chip: "Internal · Clara uses it to decide, never shares it with tenants."

D. Renewal view for one tenant: what Clara will do, and why

UX principles

• Two names, each saying who hears it, both from shipped products: Public, Internal. None names a medium ("notes", "meetings").
• One visibility chip, everywhere, same words and color: green globe Public; violet lock Internal.
• A "used by" line on every item: "Quoted in replies" vs "Used by renewals, never quoted".
• No mixed lists. A screen shows one audience. On a tenant, unit or property page, Internal is its own panel, never interleaved.
• Source one click away. Every Internal item shows its quote and opens its evidence. You edit or forget an item; you never approve it.
• Moving up is visible and deliberate: "published to Knowledge & policies by Luis".

Fede's pilot (2026-10-02): basic leasing questions plus renewals. Basic leasing questions are answered from Public, as today. Renewals are the first workflow that reads Internal.

Example 1: renewals

In client meetings Clara gathers which tenants to renew, how much to increase, whether to offer a renewal at all, and who moves to month-to-month. Each becomes an Internal item with a renewal effect.

Example 2: a leasing rule, published

Luis pastes owner call notes: "No new pets at Willow Row from November." It lands as an Internal item on the building, and Clara uses it at once with staff. Prospects hear it only once Luis publishes it to Knowledge & policies (Intercom's audience toggle is the model). Until then, if it contradicts a Public entry, Clara tells Luis the public policy is out of date.

Example 3: a maintenance signal

A nightly job sees four leak work orders on Unit 7 in 60 days and writes an Internal signal on the unit. The next time the tenant reports a leak, maintenance triage reads it and routes the call to the property manager instead of booking another routine visit. The tenant hears "I'm getting your manager involved today," never the count.

What nobody ships for us (everything else has a product or pattern to copy):

• The Public / Internal audience on property-management data, Internal by default for everything but onboarding answers and listings.
• The planted-leak test that proves Internal never reaches a tenant.
• The property-management item schema: scopes, effects, lifetimes.
• The see, edit and forget pages (the screens are copied; the data behind them is ours).

First slice (Fede: "I'm not saying go build the whole thing"):

• The item contract and the Internal store (its own key space, its own reader).
• One connector: notes forwarded to Clara's mailbox, accepted only from active staff of that company.
• One consumer: the renewal workflow at pre_first_contact, with the effect list above.
• One staff tool: get_internal_context(scope) on the staff text desk and Ask Clara.
• A company setting, default off: a new capability, so Fede turns it on per customer, after a proof at the Willows test property.

Emails, AppFolio notes, signals, meetings and outside-tool connectors come later as new connectors, not a redesign.

TL;DR: a person publishes Internal to Public (recommended); connectors run on Airbyte's open-source connectors in our AWS (recommended); listen-only joining waits for v2 (recommended); raw evidence lives 13 months (recommended).

Already settled

• Two levels in v1: Public and Internal. Every staff member sees every Internal item, including all conversations (Fede, 2026-10-02). Private is reserved in the field and built only when a customer asks.
• Names: Public and Internal, the most common words in shipped products (Fede: follow industry examples).
• Where items live: a separate store with its own reader and tools, never in the knowledge block.
• Approval: none. Items are live at once; a recap to attendees, and a plain reply corrects them (Fede, 2026-09-08). The video Clara page's renewal section still proposes an approval step and should be updated to match.
• Pilot: basic leasing questions plus renewals (Fede, 2026-10-02). First source: notes forwarded to Clara.
• Default lifetimes: lease items end with the cycle; building and company items lapse after 6 months unless restated.

One company, always

• Every item and its evidence live under the company's own node, the wall in Gera's organization model. Scope links point down to its own buildings, people and leases only.
• The company comes from the edge only: the signed-in start of the meeting, or the mailbox or number that belongs to one company. Never from what is said or written.
• Matching names to records sees only that company's records, so "the Garcias" can never resolve to another customer's tenant.
• Every read carries the company the workflow already pinned (the renewal workflow pins company and building at start).
• When a customer leaves, the purge takes their items and evidence with it.

Never stored, never acted on

• Meeting audio and video. Tavus recording and memory stay off; we keep text only.
• Card, bank and Social Security numbers: redacted before evidence is stored.
• Decisions resting on a protected class (family status, disability, race, religion, national origin, sex and the rest of fair housing). "Don't renew them, too many kids" is dropped, never acted on, and the meeting organizer is told why.
• Health details and assistance-animal specifics never go into an item.

Retention

Proposed: raw evidence for 13 months; items while valid plus 13 months for audit. A customer can delete a source, and its items go with it. See decision 4.

• The model is always there. Public knowledge works for every customer, as today.
• The setting gates new connectors, such as forwarded notes and meeting capture, not the model. It is a new capability, so it ships as a company setting, off by default, visible on the customer page, and Fede turns it on per customer.
• Off means today's behavior exactly: nothing new is captured and no Internal reads happen.
• Proof before any customer: staged meetings and forwarded notes at the Willows test property.
• Price is not designed here.

Read from propflowai origin/main at 3887385435 and 6ed1cbe8cf, 2026-10-02. The wall's code locations are in section 5.

Proposed storage, for review: PK = ORGINT#<orgId>, SK = ITEM#<scopeLevel>#<scopeId>#<validFrom>#<itemId>, plus a lookup by (orgId, scopeId). The audience attribute leaves room for a reserved Private value keyed by person id; not built. Raw evidence in S3 under a company prefix, referenced by id from each item.