Andromeda Stateful Operating System + Simple Database Plan

Date: 2026-06-01
Status: Planning document only — no implementation authorized or performed
Owner for iteration: Logan / JB / Andromeda operators
Prepared by: Juan
Primary decision captured: Fibery is out. Andromeda needs a stateful operating system with a simple database layer in the middle — not another app-shaped junk drawer with a logo.

0. Recommendation first

Use a simple Postgres-backed operational state database as the durable middle layer for Andromeda, with Google Sheets, Discord/Hermes, CRM, Google Drive, and the dashboard treated as interfaces/views, not the actual brain.

Plain version:

Sources of activity
  Dodge / Gmail / Drive / Discord / Omi / manual notes / CRM / sheets
        ↓
Raw event log + normalized operational database
        ↓
Review queues, approvals, status, tasks, relationships, audit trail
        ↓
Human views
  Google Sheets, dashboard, Discord briefings, CRM records, Drive packets
        ↓
Approved actions only
  CRM writes, outreach, Dodge writes, bid packets, task assignments

The database should not become a custom CRM, custom PM app, or custom everything-machine on day one. That is how projects turn into a swamp wearing a dashboard costume.

The database should do five boring but critical jobs:

Remember state — what happened, what changed, who reviewed it, what the current status is.
Connect entities — projects, companies, contacts, files, notes, emails, bid opportunities, tasks, approvals.
Protect humans from duplicate work — no re-reviewing the same Dodge lead every morning like Groundhog Day with addenda.
Gate side effects — nothing writes to CRM, Dodge, email, legal/compliance, or bids without a human approval record.
Feed many surfaces — Sheets for Karen, dashboard for command view, Discord for summaries, CRM for approved relationships.

Recommended base: Postgres on the existing Andromeda VPS, because it is already part of the architecture and gives Andromeda portability. Keep the schema intentionally small. If real-time UI becomes the center of gravity later, add a thin app/API on top. Do not start with a bloated work-management SaaS just because it promises “everything in one place.” That usually means “everything half-owned by nobody.”

1. What changed

1.1 Fibery is no longer in the plan

User direction from 2026-06-01:

“We are no longer looking at using Fibery.”

So this plan removes Fibery from the architecture. No Fibery dependency, no Fibery data model, no Fibery workflow assumptions.

1.2 The “stateful system” point is the center

The useful shift is this:

Andromeda does not just need better chat, better sheets, or another CRM. It needs a stateful operating layer that knows:

this Dodge project was seen before;
Karen marked it hot;
Logan rejected a similar type last week;
Corey needs to review if bonding/license risk appears;
a GC was already contacted, or more accurately, a draft exists but was not approved;
a project disappeared from today’s source feed but should not be treated as dead;
a human note must survive automation refreshes;
a CRM write is proposed but not approved;
a file packet exists in Drive;
a later email reply should attach back to the same opportunity.

That is state. Without it, every tool becomes a pretty amnesiac. We already have enough of those in software. Construction doesn’t need another one.

1.3 “Simple database in the mix” is right

A simple database gives Andromeda a neutral spine:

Sheets can stay lightweight and human-friendly.
CRM can stay focused on approved contacts/companies/pursuits.
Dashboard can be a view, not a trap.
Discord can stay a command/review surface, not the record of truth.
Agents can coordinate without turning chat history into infrastructure.

2. Sources checked for this plan

This plan is grounded in the current Andromeda docs and skills, especially:

/srv/andromeda/docs/architecture.md
/srv/andromeda/docs/team-agent-architecture.md
/srv/andromeda/docs/andromeda-ai-setup-todos.md
/srv/andromeda/docs/docs__crm.md
/srv/andromeda/docs/nextcrm-dashboard-cutover.md
/srv/andromeda/docs/andromeda-dodge-ai-bid-pipeline-master.md
andromeda-crm-pilot skill
andromeda-dodge-triage skill
andromeda-ops-dashboard skill
andromeda-company-context skill

Important note: the local Dodge master doc and the current runtime/skill memory are not perfectly aligned on Sheet tab names. Current operating memory says the visible tabs are:

A1 Active Bid Review
A2 Follow
A3 Schmooze
No-Go
Hot List
Deleted / Suppressed
A1 Disposition
Overall Logic

The local master doc still contains older tab language like A1 Review Today, A2 Inspect Docs, A4 Follow Award, A5 Relationship Target, and Karen Hot List in places. Before implementation, verify the live sheet and update the master doc only if Logan explicitly asks. The database design should not hard-code fragile sheet names anyway. It should store durable states and let sheets be replaceable views.

3. Core design principle

3.1 Separate the data plane from the interface plane

This remains the right principle from the existing architecture docs:

Data plane: portable, durable, backed up, owned by Andromeda.
Interface plane: swappable tools humans actually use.

The mistake to avoid is letting any one interface become the system of record just because it is convenient this week.

3.2 Proposed model

DATA PLANE
- Postgres state database
- Google Drive documents / source files
- local VPS artifacts and logs
- exportable CRM records
- audit and approval ledger

INTERFACE PLANE
- Google Sheets review workbooks
- Discord/Hermes summaries and commands
- CRM UI for approved relationships and deals
- dashboard.andromedacon.com / future command center
- Google Drive folders and docs
- mobile/voice/Omi capture views

3.3 Rule of thumb

If a human edits it directly and expects to see it visually, it is probably an interface.

If automation must remember it, reconcile it, audit it, or connect it to other things, it belongs in the state database.

4. What the database is — and is not

4.1 The database is

A state spine for operations:

source records,
normalized entities,
review queues,
status transitions,
human decisions,
approval gates,
sync run history,
links between systems,
auditability.

4.2 The database is not

At least at first, it is not:

a replacement for Google Drive;
a replacement for CRM;
a replacement for Google Sheets;
a replacement for email;
a replacement for human judgment;
a public/client portal;
an estimating platform;
a legal/compliance decision maker;
a place for secrets;
a giant custom app we now have to feed, groom, and pretend is “almost done.”

4.3 Best mental model

Think of it as Andromeda’s operational memory and traffic controller.

Humans still drive. The database keeps the intersection from turning into four trucks, three trailers, and Karen’s notes all meeting in the middle with no stop signs.

5. Why Postgres is the recommended database

5.1 It already fits the current architecture

Existing docs already identify Postgres on the VPS as the structured-data layer for:

Dodge leads,
scores,
outreach logs,
feedback signals,
embeddings / future search support,
tool-call logs / audit trails.

Postgres is already installed in the live architecture inventory. That does not mean implementation should start today. It means the planning decision has a sane default and does not require inventing a new vendor dependency.

5.2 It keeps the data portable

Postgres is boring. Boring is good here.

Benefits:

exportable;
inspectable;
works with almost every dashboard and app framework;
supports audit logs and JSON raw payloads;
supports relational links between projects/companies/contacts/tasks;
can grow from simple tables to richer workflows;
does not trap Andromeda inside one SaaS product.

5.3 It supports “simple now, stronger later”

Start with simple normalized tables plus JSON raw payload retention. Later, add:

full-text search,
vector embeddings,
event replay,
dashboards,
APIs/MCP tools,
stricter permissions,
sync jobs,
reporting views.

Do not start with the advanced stuff unless the boring stuff is working. A fancy embedding index over messy status data is just lipstick on a raccoon.

6. Recommended system map

6.1 High-level flow

1. Capture
   Dodge, Gmail, Drive, Discord, Omi, CRM, manual notes, sheets

2. Store raw event
   Append-only raw source event with source, timestamp, payload/ref, hash

3. Normalize
   Extract project/company/contact/file/task/decision candidates

4. Resolve identity
   Match to existing opportunity, company, contact, project, or document

5. Classify and route
   Apply scoring, rule tags, risk flags, approval requirements

6. Present to humans
   Sheet row, dashboard card, Discord summary, CRM review queue

7. Human decision
   approve, reject, defer, hot-list, suppress, bid-review, CRM-candidate

8. Approved side effect
   CRM write, email draft/send, Drive packet, Dodge follow/tag, task creation

9. Audit and feedback
   Store who decided, what changed, why, and what Juan should learn

6.2 Current / near-term interfaces

Interface	Role	Database relationship
Dodge	Source of project/opportunity intelligence	Raw source + normalized opportunity records; read-only unless approved
Google Sheet staging workbook	Human review surface	View/export/sync surface; not the durable state by itself
Hot List	Human feedback and primitive CRM lane	Should become structured human feedback / candidate status in DB
CRM / Zoho / Twenty target	Approved relationship/pursuit system	Downstream of human approval, not raw intake dumping ground
Google Drive	Document/file source of truth	DB stores file metadata, links, packet status, not necessarily file contents
Discord/Hermes	Command and review surface	DB stores resulting records/approvals, not random chat as truth
Omi	Private capture layer	Raw/private intake first; approved summaries can become shared records
Dashboard app	Command-center view	Read/write UI on top of DB after security review
Agent handoff queue	Phase-1 durable coordination	Can later map into DB task/handoff tables

7. Proposed database domains

The database should be organized around domains, not apps.

7.1 Source and event domain

Purpose: preserve what came in and when.

Candidate tables:

source_systems
raw_events
source_records
sync_runs
source_record_versions
ingest_errors

Stores:

Dodge payload references,
Gmail message metadata,
Drive file change events,
Omi transcript references,
Discord command references,
sheet edit snapshots,
CRM webhook events.

Why it matters:

If something changes downstream, Andromeda can answer: “What did we actually receive, and when?” That beats reconstructing reality from vibes and screenshots.

7.2 Entity domain

Purpose: stable records for real-world objects.

Candidate tables:

organizations
people
contacts
contact_methods
projects
opportunities
locations
documents
files
equipment later
crews_or_resources later

Important distinction:

A project may be an actual Andromeda job, development, property, or construction effort.
An opportunity may be a Dodge lead, bid possibility, relationship target, or future pursuit.

Do not collapse those too early. A Dodge opportunity is not automatically an Andromeda project. That little mistake is how CRMs become fiction shelves.

7.3 Relationship domain

Purpose: connect people, companies, projects, opportunities, and roles.

Candidate tables:

organization_roles
project_participants
opportunity_participants
relationship_targets
warm_intro_paths
source_contact_mentions

Examples:

Owner on project,
GC / bidder / planholder,
civil engineer,
architect,
municipal buyer,
subcontractor candidate,
relationship target,
known prior Andromeda contact.

This is where A3/A5-style relationship intelligence should eventually live, even if the review surface remains a sheet.

7.4 Workflow state domain

Purpose: current status, routing, next action, and lifecycle.

Candidate tables:

review_items
workflow_states
status_transitions
routing_decisions
human_feedback
suppression_registry
hot_list_marks
tasks
handoffs
blockers

This domain answers:

What queue is this in?
Why is it there?
Who needs to look at it?
What happened last time?
Is it suppressed?
Did Karen mark it hot?
Is Corey review required?
Is there an approved next step?

7.5 Approval and side-effect domain

Purpose: prevent unauthorized writes and public actions.

Candidate tables:

approval_requests
approval_decisions
outbox_actions
external_write_attempts
external_write_results
audit_log

Side-effect classes requiring approval:

CRM write,
email send,
vendor/customer/GC/owner contact,
Dodge tag/follow/note/export/download/write,
bid submission,
legal/contract/certification/bonding/insurance action,
pricing or financial commitment,
public website/marketing claim if fact-sensitive.

The outbox pattern is key:

Draft/proposed action
  -> approval request
  -> human approval
  -> external write/send
  -> result logged

No approval record, no action. Pretty simple. Also prevents “the AI did what?” meetings, which are nobody’s favorite kind.

7.6 Scoring and intelligence domain

Purpose: keep AI/classifier output explainable and tunable.

Candidate tables:

scoring_runs
score_components
classifier_versions
rulesets
rule_matches
ai_recommendations
human_corrections
feedback_patterns

Stores:

score,
reasons,
rules triggered,
model/classifier version,
input snapshot reference,
human correction,
later outcome.

This protects Andromeda from black-box drift. If Karen keeps marking similar things hot, the system should learn — but not silently mutate rules without Logan/Karen approval.

7.7 Document/file domain

Purpose: connect files and packets to operational state.

Candidate tables:

file_refs
drive_items
document_packets
packet_items
packet_review_status
source_artifacts

Stores:

Google Drive file ID,
folder path,
source system,
project/opportunity link,
packet type,
current review status,
human owner,
artifact path.

Do not shove all file contents into the database. Store references, metadata, extracted summaries where useful, and hashes/version pointers. Drive remains the human file source.

7.8 Communications domain

Purpose: track touchpoints, drafts, replies, and follow-ups.

Candidate tables:

communications
communication_drafts
email_threads
message_refs
call_notes
meeting_notes
follow_up_tasks

This should only become active after approval rules are clear. Drafting is fine. Sending requires approval.

8. Minimum viable database shape

Do not build all domains at once. The minimum useful version should support the current Dodge + review + approval loop.

8.1 MVP tables

Recommended MVP table set:

source_systems
raw_events
opportunities
organizations
people
opportunity_participants
review_items
human_feedback
tasks
approval_requests
outbox_actions
sync_runs
audit_log

That is enough to prove the stateful pattern without building a digital cathedral nobody asked for.

8.2 MVP fields — examples, not final schema

`opportunities`

id
source_system
source_record_id
source_url
title
description_summary
county
city
state
bid_date
estimated_value
stage
opportunity_type
scope_tags
current_status
created_at
updated_at
last_source_seen_at

`review_items`

id
opportunity_id
review_lane
priority
routing_reason
risks_blockers
recommended_action
assigned_to
status
due_at
created_at
updated_at

`human_feedback`

id
opportunity_id
human_id
feedback_type
feedback_value
notes
source_surface
created_at

Examples:

hot_list = yes
suppress = yes
no_go_reason = too_far
crm_candidate = needs_review
classifier_wrong = yes

`approval_requests`

id
requested_by
requested_for_action_type
target_entity_type
target_entity_id
proposed_payload
risk_class
status
approver
decision_at
decision_notes

`outbox_actions`

id
approval_request_id
action_type
target_system
payload
status
attempted_at
result_summary
external_record_id

8.3 MVP principle

The MVP database should first prove:

deduplication,
state retention,
human feedback preservation,
approval gating,
audit trail,
dashboard/sheet read model.

If it cannot do those, adding more fields is just decorating the pothole.

9. Dodge pipeline fit

9.1 Current Dodge flow

Current operating shape:

Dodge saved searches / approved feed or export
  -> Juan read-only fetch + classification
  -> Google Sheet review workbook
  -> Karen / Logan / Corey review
  -> Hot List / Follow / Schmooze / No-Go / Suppressed / CRM candidate
  -> approved CRM/outreach/bid actions only

9.2 What the database changes

The database should eventually sit between raw Dodge intake and the Sheet output:

Dodge source fetch
  -> raw_events / source_records
  -> normalized opportunities
  -> scoring + routing
  -> review_items
  -> Sheet view/dashboard view
  -> human feedback back into DB

The Sheet remains useful. It just stops being the only place state survives.

9.3 Why this matters for Dodge

Dodge has exactly the kind of data that punishes stateless workflows:

projects reappear;
bid dates move;
project names vary;
planholders change;
addenda arrive;
old opportunities become relationship targets;
“not seen today” does not mean “dead”;
human notes must survive refreshes;
suppression must persist;
Hot List choices are training data.

A state DB handles that cleanly.

9.4 Dodge-specific database states

Suggested opportunity lifecycle states:

source_seen
normalized
scored
queued_for_review
active_bid_review
follow_award_or_update
relationship_target
hot_listed
suppressed
no_go
crm_candidate_pending_approval
crm_synced
outreach_draft_pending_approval
outreach_sent
bid_review_needed
bid_submitted only after human action record
closed_lost
closed_won
archived

The sheet tab names can change. The states should stay stable.

9.5 Dodge guardrails preserved

No change to existing guardrails:

no Dodge UI scraping;
no Dodge writes without approval;
no tags/follows/notes/exports/downloads/CRM/outreach/bid actions unless explicitly approved;
humans handle login/MFA;
licensed data stays controlled;
source retention follows Dodge terms.

The database should help enforce these rules, not quietly work around them. Quiet workarounds are how you get expensive surprises in a safety vest.

10. CRM fit

10.1 CRM should be downstream, not the intake swamp

CRM is for approved relationships, contacts, companies, opportunities, tasks, and follow-ups that humans intend to manage.

CRM should not receive every raw Dodge item or every noisy contact mention.

Recommended flow:

Database opportunity / relationship intelligence
  -> human review
  -> approved CRM candidate
  -> CRM upsert proposal
  -> human approval
  -> CRM write
  -> CRM record IDs stored back in DB

10.2 Zoho / Twenty / custom dashboard split

Current docs say:

Zoho remains useful for immediate Dodge pilot testing.
Twenty Cloud was the earlier target recommendation.
dashboard.andromedacon.com / NextCRM exists and needs security/access/product-fit review before deeper operational data enters it.

Recommended position for now:

Do not force a CRM cutover as part of the database decision.
Use the database as the staging/state layer.
Keep CRM writes behind approval.
Let Zoho/Twenty/custom dashboard be evaluated as interfaces and downstream systems.

This keeps the architecture from depending on the CRM decision being perfect. Because if there’s one thing software vendors love, it’s making the “final answer” age like milk.

10.3 Database vs CRM responsibilities

Responsibility	Database	CRM
Raw Dodge intake	Yes	No
Scoring/classification runs	Yes	No
Human review status	Yes	Maybe view only
Hot List / suppression feedback	Yes	Only approved candidates
Approved companies/contacts	Reference/cross-link	Yes
Outreach history	Store approved sync refs	Yes, once approved
Tasks/follow-ups	Operational queue; may sync	CRM for approved BD tasks
Audit log	Yes	Partial
Source payloads	Yes, controlled	No

11. Dashboard fit

11.1 Dashboard should be a command surface, not the database

The Andromeda dashboard should answer:

What needs attention today?
What is blocked?
What is hot?
What changed?
What needs approval?
What is waiting on Karen, Logan, Corey, Cheryl, or an outside party?
What can Juan draft but not send?

The dashboard should read from and write approved state to the database, not become the only place state exists.

11.2 Existing NextCRM / dashboard.andromedacon.com

Existing facts from docs:

dashboard.andromedacon.com routes to NextCRM on the Andromeda VPS.
It was live as of 2026-05-04.
It contains AI Implementation project/task scaffolding.
Google OAuth was not configured in the cutover note.
Docs still call for security/access review before deeper operational data enters it.

Recommended plan:

Treat current dashboard as a candidate interface, not confirmed system of record.
Review its data model, auth, export, backup, and role behavior.
If useful, connect it to the state DB through a controlled API or read model.
If not useful, keep the DB and swap the dashboard. That is the whole point of separating layers.

11.3 Dashboard views to plan

Future dashboard cards/views:

Today’s Dodge review queue
Hot List / bid-candidate lane
Follow / award watch lane
Relationship targets / schmooze lane
No-Go / classifier tuning lane
Approval requests
CRM candidate proposals
Outreach drafts pending approval
Active jobs / project command board
Omi/meeting capture review queue
Drive packets needing review
Weekly pipeline report
Errors / sync failures / stale data watchdog

Start with read-only views. Then add controlled edits. Then add approved writebacks. Do not reverse that order unless we are trying to create a haunted house with buttons.

12. Google Sheets fit

12.1 Keep Sheets where they are useful

Sheets are good for:

Karen review;
fast visual scanning;
manual notes;
simple dropdowns;
shared lightweight decision-making;
low-training adoption.

Sheets are bad as the only durable backend for:

identity resolution;
audit trails;
external sync state;
complex approval history;
multi-source event tracking;
row lifecycle across changing source feeds.

12.2 Sheet as view pattern

Recommended pattern:

Postgres state tables
  -> generated Sheet output tabs
  -> Karen/Logan human edits in allowed columns
  -> sheet edit reader / periodic sync
  -> human_feedback + review state in Postgres
  -> next generated output preserves state

Human-owned columns must remain protected/preserved:

Hot List marking / keep decision,
Karen notes,
status overrides if approved,
suppression choices,
contact corrections,
relationship intel.

12.3 Avoid sheet-name dependency

Because sheet names are already evolving, database state should use durable concepts:

active_bid_review
follow
relationship_target
no_go
hot_list
suppressed
disposition
logic_reference

Then map those to current tab names in configuration.

13. Google Drive and document control fit

13.1 Drive remains the human file source

Current direction remains right:

Drive is human source of truth for documents.
VPS/local mirror gives agents fast/readable access.
Agents write outputs into controlled review areas first.
Sensitive/legal/financial/personnel/private content remains permission-scoped.

13.2 Database role for Drive

Database stores:

Drive item ID,
folder ID/path,
document type,
linked opportunity/project/company/person,
packet status,
review status,
source hash/version,
extracted summary pointer,
approval state if a generated packet is ready.

Database should not silently overwrite canonical Drive docs.

13.3 Project packet flow

For bid/project packets:

Opportunity needs packet
  -> create packet request in DB
  -> gather Drive/source refs
  -> generate draft packet in review folder
  -> human reviews
  -> approved packet marked ready
  -> any external send still requires approval

14. Discord, Hermes, Omi, and agent handoffs

14.1 Discord is the command/review surface

Current team architecture says Discord is not the coordination brain. That stays correct.

Discord should be used for:

asking Juan/Nana/Juno questions;
approving or rejecting specific proposed actions;
surfacing summaries;
reporting failures;
linking to records/views/docs.

It should not be the only place decisions live.

14.2 Omi is private capture first

Omi transcripts should land in private owner queues first, then produce structured review items:

action item candidates,
contact/company/project mentions,
decision candidates,
follow-up reminders,
possible CRM updates,
possible project notes.

Raw Omi content should not automatically become shared company knowledge.

14.3 Handoff queue evolution

The file-backed handoff queue is a good phase-1 bridge. Later, it can map into database tables:

handoffs
tasks
approval_requests
review_items
audit_log

Recommended migration path:

Keep file-backed queue now.
Define equivalent DB fields.
Run in parallel read-only once ready.
Promote DB as canonical only after humans trust the views.

15. Approval model

15.1 Approval classes

Every proposed side effect should have an action class.

Action class	Examples	Default
`read_only_analysis`	summarize Dodge, inspect docs, classify	Allowed if source access is authorized
`internal_note`	add review note, draft recommendation	Allowed in approved internal systems
`internal_state_update`	mark reviewed, hot-list, suppress	Allowed only in defined review surfaces / DB
`crm_write`	create/update contact, company, opportunity	Approval required
`email_send`	send vendor/customer/GC/owner email	Approval required
`dodge_write`	tag/follow/note/export/download/write	Approval required by side-effect class
`bid_action`	submit bid, pricing, bond, addendum commitment	Explicit human action only
`legal_compliance`	license, certification, contract, insurance	Explicit human/legal review
`financial`	payment, procurement, purchase commitment	Explicit human approval
`public_claim`	website/SOQ/marketing claim	Source verification + approval

15.2 Approval record format

Each approval request should capture:

proposed action,
target system,
target record/entity,
draft payload,
risk class,
requested by,
requested at,
approver,
decision,
decision at,
decision notes,
external result if executed.

15.3 Approvals should be specific

Bad approval:

“Juan can update CRM.”

Better approval:

“Juan may create a CRM Deal and Contact for Dodge project X using the shown payload, assign to Karen, and log this note. No email send.”

Specific approvals prevent scope creep. Scope creep is just unauthorized work wearing nicer shoes.

16. Identity and deduplication rules

16.1 Stable IDs

Every source record should preserve source IDs where available:

Dodge project ID,
Google Drive file ID,
Gmail message/thread ID,
CRM record ID,
Sheet row source ID,
Discord message ID if available to a bot/tool,
Omi conversation/export ID.

16.2 Entity matching

The DB needs conservative matching:

exact source ID beats fuzzy match;
exact email/domain helps for companies/contacts;
company names need normalization;
people can have multiple roles;
projects can have similar titles;
county/location/date/scope helps match opportunities;
uncertain matches require review, not blind merge.

16.3 Merge policy

Never silently merge high-value entities when uncertain.

Use statuses:

confirmed_match
possible_match
conflict
needs_human_resolution

Better a duplicate candidate than a bad merge. Bad merges are digital concrete poured in the wrong form.

17. Data quality and observability

17.1 Required sync run tracking

Every automated run should log:

started at,
finished at,
source system,
records read,
records created,
records updated,
records skipped,
errors,
output artifacts,
verification result.

17.2 Contract checks

For each interface:

Sheet tabs exist and populated;
links remain clickable;
human-owned columns preserved;
DB row counts make sense;
CRM writes match approved payload;
dashboard view matches DB query;
no raw secrets leak into docs/output.

17.3 Failure behavior

If sync cannot read existing human-owned state, it must not overwrite the output surface.

For example:

If Sheet read fails, do not clear the review tabs.
If CRM lookup fails, do not create duplicates blindly.
If Dodge auth fails, report the fetch blocked and preserve last known queue.
If Drive access fails, do not invent packet status.

A stale but intact queue beats a fresh pile of wrong output every day of the week.

18. Security, privacy, and retention

18.1 Secrets

Do not store secrets in the database planning docs, Drive docs, Discord, or memory.

Secrets belong in:

private .env files with restricted permissions,
credential stores,
platform OAuth storage,
future 1Password/Doppler-style vault if adopted.

18.2 Data sensitivity levels

Suggested sensitivity levels:

public_safe
internal_company
private_owner
legal_contract_sensitive
financial_sensitive
credential_secret — should not be stored as content
licensed_source_restricted — Dodge and similar

18.3 Retention

Define retention by source:

Dodge data: follow license/contract terms.
Email metadata/body: only where authorized and useful.
Omi raw transcripts: private by default; retention deliberately chosen.
Generated drafts: retain if tied to approval/audit; otherwise archive/prune.
Audit logs: keep long enough to support operational review.

18.4 Access model

Initial roles:

Owner / Logan: all approved internal data.
Operator / Karen: bid pipeline, CRM, follow-up, project docs as appropriate.
Cheryl/Juno: website/process/support lanes as assigned.
Corey: estimating/risk review lane when activated.
JB/Mia support: setup/support scope, not standing access to private owner material unless approved.
Agents: least privilege; shared company docs/skills plus their authorized systems.

19. Reporting and review cadence

19.1 Daily

New/changed Dodge opportunities.
Hot List movement.
Approval requests pending.
Sync failures.
Today’s bid/review deadlines.

19.2 Weekly

Opportunities added.
Hot List additions.
No-Go/suppression patterns.
Classifier corrections.
CRM candidates approved/rejected.
Outreach drafts/sends approved.
Follow-up overdue list.
System errors and data-quality issues.

19.3 Monthly

Which workflows humans actually used.
Which outputs were ignored.
Which data fields were useless clutter.
Which approval gates can remain manual or become standing rules.
Whether CRM/dashboard choice still fits.
Whether to expand beyond Dodge into active jobs, finance/admin, labor/equipment.

Kill or simplify workflows nobody uses. Zombie workflows eat more time than they save.

20. Phased plan — no implementation yet

Phase 0 — Agreement on architecture

Goal: Decide the shape before touching systems.

Deliverables:

Confirm Fibery is out.
Confirm Postgres/simple DB as state spine.
Confirm Sheets remain review surface.
Confirm CRM remains downstream of approval.
Confirm dashboard is a view/interface, not source of truth yet.
Confirm approval classes.
Confirm first domain: Dodge/opportunity state.

Decisions needed:

Is Postgres the approved default state DB? Juan recommends yes.
Is Dodge/opportunity workflow the first proof? Juan recommends yes.
Should DB store only internal state first, with no external writes? Juan recommends yes.
Who approves CRM-write pilot records? Logan/Karen.
Who owns schema decisions? JB/Logan with Juan drafting, Karen validating usability.

Phase 1 — Paper schema and workflow model

Goal: Design the database on paper before creating tables.

Deliverables:

Entity list.
State machine for opportunities.
Approval model.
Source-system map.
Sheet view mapping.
CRM mapping.
Dashboard read-model sketch.
Security/sensitivity tags.
Backup/restore expectations.

No code. No schema migration. No production writes.

Phase 2 — Read-only prototype design

Goal: Plan how a prototype would read current artifacts without changing them.

Deliverables:

Dodge source mapping.
Existing Sheet mapping.
Human fields preservation plan.
Sync-run logging plan.
Verification checklist.
Rollback/non-destructive testing plan.

Still no implementation unless separately approved.