Memory / Facts - 3 wall-tagged scopes + editable cards¶
| Stage | Estimated |
|---|---|
| Status | Deferred |
| Design status | In review |
| Estimate | 2w (L) |
| Confidence | Low |
| Linear | PIN-1025 ↗ |
| Linear status | Todo |
| Cycle | C15 |
| Design | Design ↗ |
| Linear epic | Cara AI & Automation |
| Module | Cara ↗ |
Priority: Medium
Conor's comments¶
Part of the Jonny build. Need to understand how we can derive relevatn key memories that would be posted such as delays, COs, etc.
Notes¶
The moat. Learning events fire today but are write-only
Open question for Conor¶
Q-2 memory scope (three recommended)
Scope (from canceled PIN-320)¶
PIN-320 was the spec-authoring ticket for the Cara memory layer. It was canceled in the 2026-08-26 cleanup, so its scope is folded here so it is not lost:
- Profile schema per entity type: client, subcontractor, employee, project, GC, vendor
- What gets remembered: decisions, conversations, outcomes, preferences, history
- Learning signals: how each workflow (vendor pricing, bid outcomes, document classification) feeds the memory layer
- Retention policy: how long facts are kept, what gets discarded
- Cross-workflow access: how a memory surfaces in the right context
- Privacy and tenant boundaries at a high level, with the deeper tenant policy tracked separately
- Patent claim opportunities: likely a continuation filing off the March provisionals
Memory itself is Jonny's build. This page covers how Cara derives and surfaces the key memories (delays, COs, and similar) as editable fact cards.