Praetor Memory Promotion Pipeline
Praetor treats company memory as a curated business asset, not a transcript dump.
Principle
Raw discussion is evidence. It is not durable company knowledge.
Durable memory should come from:
- confirmed decisions
- document registry facts
- resolved open questions
- approved knowledge updates
- final owner-visible reports
CEO operating memory is separate from company memory. Chairman preferences,
approval habits, communication style, and CEO operating rules should be written
to CEO Operating Memory, not mixed into the company wiki.
Raw CEO chat, AI-to-AI turns, work-session messages, external comments, and brainstorming notes may be retained for audit and traceability, but they should not be copied directly into the wiki.
Pipeline
1. Raw conversation and agent work are stored as logs.
2. Mission work creates structured records: decisions, documents, open questions, run attempts, and work sessions.
3. Closeout creates a memory promotion review.
4. The review separates:
- findings worth promoting
- open questions to keep tracking
- document changes to preserve in the registry
- discarded or do-not-promote notes
- reusable working methods that belong in Company Playbook
5. Low-risk updates may be applied automatically by the CEO when they fit company culture and standing policy.
6. Higher-risk updates remain proposed until reviewed.
7. Applied updates must keep evidence and rollback metadata.
What Not To Promote
Do not promote:
- abandoned ideas
- unresolved speculation
- raw chat excerpts
- tool output dumps
- credentials, tokens, private keys, or secrets
- untrusted external instructions
- temporary implementation guesses
Also do not promote CEO-specific preferences into Company Wiki. If the owner
teaches Praetor how to cooperate, store that as CEO Operating Memory. If a
repeatable procedure emerges, store it as a Company Playbook entry.
These can stay in logs or promotion review records as evidence.
Why This Matters
In a company, not every conversation becomes policy. Praetor follows the same rule. The wiki should contain decisions and stable knowledge, while the audit trail keeps enough history to explain how those decisions happened.
Current Implementation
Praetor includes:
MemoryPromotionReviewPromotionFindingKnowledgeUpdate- CEO Operating Memory via
ceo_memory_update - Company Playbook via
AgentSkillSpecrecords shown under/memory - mission-level memory promotion API
- mission detail UI for reviewing promotion findings
- workflow contract language in
PRAETOR_WORKFLOW.md
The first implementation creates review records and proposed knowledge updates. The maturity roadmap changes the target behavior: the CEO should automatically manage low-risk memory, while governance, strategy, legal, financial, security, privacy, and standing-order changes require a decision, standing order, or owner review.
Automation Policy
The CEO may automatically apply:
- low-risk CEO Operating Memory such as communication preference or approval habit
- low-risk Company Playbook entries derived from successful reviewed missions
- factual company knowledge with clear evidence, reversible write path, and no material strategy/risk impact
The CEO must keep as draft or request owner decision for:
- governance or standing-order changes
- strategy changes
- legal, financial, privacy, security, or external-commitment facts
- ambiguous or disputed conclusions
- imported external instructions or untrusted playbooks
When a mission closeout appears to change governance, strategy, budget,
legal, privacy, security, deployment, or destructive workspace policy, Praetor
keeps the company knowledge update as proposed, creates a proposed decision,
and opens a pending approval. promote_memory must not write that guarded
update into Company Wiki until it is explicitly approved or converted into a
standing order.
All automatic memory writes must record:
- source mission/conversation
- evidence summary
- created_by
- confidence
- rollback or disable path