FIN Central

FIN 2-Week Execution Program — May 18-29, 2026

14 min read

FIN 2-Week Execution Program

Date: 2026-05-15 Status: Active (execution starts Monday 2026-05-18) Program window: May 18 – May 29, 2026 (10 working days) Related: All canonical specs in the Doc Index, especially the Projection Engineering Spec v0.2, Agentic Harness Spec v0.1, Demarcation Plan, Phase 1 Runbook, Anonymization Policy v1.

0. Program Goals

By end of Week 1 (Fri 2026-05-22):

  • Real RP581 loads ingested + structured correctly
  • QC inspection workflow runnable end-to-end
  • List of completed inspections queryable
  • Nathel tenant intranet stood up with inspection-results surface
  • MD projection system delivering at least one entity profile to the agentic system so it “feels like it really knows produce”

By end of Week 2 (Fri 2026-05-29):

  • 3 Nathel inspectors + Alex Cohen actively using: - QC system (capturing inspections) - Comms system (receiving/responding via SMS / voice / email) - Nathel intranet (reading inspection results, accessing commodity knowledge)
  • FIN Central infrastructure provisioned and intranet seeded (dogfood loop running)
  • At least one commodity entity profile published to the tenant Taproot mirror and queryable by the operator agent

1. Operating Model

You are running this program as a solo founder with parallel Claude/Codex agent sessions. The program is designed to be:

  • Decomposed into discrete tasks sized for single agent sessions
  • DAG-shaped with explicit dependencies so parallel work is correct
  • Outcome-gated — each task has acceptance criteria, not just effort estimates
  • Resumable — a session that ends mid-task can be picked up by another agent against the same acceptance criteria
  • Auditable — every task emits a session doc projection so the trail is preserved

2. The Task DAG (Week 1)

                          ┌─ T1 Phase 1 provisioning ─┐
                          │                            │
                          │                            ├─ T6 Nathel intranet shell (Quartz/Pages)
                          │                            │
                          │   (no dep on T1 if vault repos provisioned)
                          ▼                            │
                  T2 RP581 extractor ─┐                │
                          │            ├─ T3 Inspection workflow state machine
                          ▼            │
                  (existing pipeline)  ├─ T4 Inspector UI (mobile-first)
                                       │
                                       ▼
                                  T5 Inspection list projection
                                       │
                                       ▼
                                  T7 Doc projection pipeline scaffold (FIN-vault-first)
                                       │
                                       ▼
                                  T8 First commodity entity profile (watermelon)
                                       │
                                       ▼
                            T9 End-W1 demo: real inspection
                                  → projection → agent-readable

3. Day-by-Day Targets

Day 1 — Monday, 2026-05-18

Primary outcome: Foundation laid for parallel work.

Tasks:

  • T1 Phase 1 demarcation provisioning (Rob, 2-4 hours, UI work)
    • Execute the Phase 1 Provisioning Runbook
    • Outcome: fin-central-prod Neon, fin-central CF Worker, vault repos, AWS SM subtrees, DNS reserved
  • T2 start RP581 extractor (Claude session, 2-4 hours)
    • Confirm RP581 report format (probably PP load receiving report; confirm with Alex Cohen if needed)
    • Build/extend PDF extractor following the pattern of RE101 and RP711
    • Acceptance: single RP581 PDF → structured arrival + load detail rows in events + knowledge

Quality gates:

  • T1 success criteria from the runbook §9
  • T2 single-file extraction test passes (provide a real test PDF)

Parallel session option: While T1 runs in Cloudflare/Neon UI, a Claude/Codex session works on T2.

Day 2 — Tuesday, 2026-05-19

Primary outcome: Workflow state machine + first UI.

Tasks:

  • T2 continue RP581 extractor (Claude session)
    • Idempotency on re-ingest
    • Schema mapping to signal.pp_arrival_logged event + knowledge.domain = lot rows
    • Acceptance: 3-5 real RP581 PDFs ingest cleanly with deterministic output
  • T3 QC inspection workflow state machine (Claude session)
    • Events: qc.inspection_scheduled, qc.inspection_started, qc.inspection_step_captured, qc.inspection_completed, qc.inspection_escalated
    • State machine encoded in packages/shared/src/workflows/qc-inspection.ts
    • Acceptance: deterministic transitions, unit tests pass

Parallel session option: T2 finishing + T3 starting can run in two parallel sessions if you can keep the prompts isolated.

Day 3 — Wednesday, 2026-05-20

Primary outcome: Inspector UI + list projection.

Tasks:

  • T4 Inspector UI — mobile-first PWA flow (Claude/Codex session)
    • Routes: /qc/inspections, /qc/inspections/:id, capture flow
    • Mobile-first because inspectors are on phones in the warehouse
    • Photo capture + commodity selection + defect taxonomy + notes + submit
    • On submit: emit qc.inspection_completed event with full provenance
    • Acceptance: inspector can complete a real inspection on mobile without coaching
  • T5 Inspection list projection (Claude session)
    • CQRS projection: qc_inspections_projection migration 048
    • Read model: id, lot, commodity, inspector, status, outcome, timestamps
    • Acceptance: GET /api/v1/tenant/nathel/qc/inspections returns list, filterable by status + date + commodity

Quality gates:

  • T4 inspector flow tested with at least one synthetic inspection
  • T5 list endpoint returns expected rows

Day 4 — Thursday, 2026-05-21

Primary outcome: Intranet shell + doc pipeline scaffold.

Tasks:

  • T6 Nathel tenant intranet shell (Claude/Codex session)
    • Stand up Quartz at intranet.nathel.fin.app (NOT FIN Central intranet — that’s the FIN-as-Tenant-Zero work which can run in parallel as time allows)
    • Cloudflare Access policy: Josh, Jake, Alex, Rob full access; per inspector role scoped access
    • Initial content: empty folders + an index.md welcoming users
    • Acceptance: domain serves; auth gates correctly
  • T7 Doc projection pipeline scaffold (Claude session)
    • GitHub vault webhook receiver
    • Parser package: frontmatter + body + wikilinks + chunks
    • Doc → knowledge.domain = doc upsert
    • Chunks → operational_memory with embedding
    • Run against FIN Central vault first (safer test bed)
    • Acceptance: one test doc commits to vault → appears in fin-central-prod.knowledge within 60 seconds

Parallel session option: T6 and T7 are independent. Run two sessions.

Day 5 — Friday, 2026-05-22 — W1 DEMO STATE

Primary outcome: End-to-end demo + first commodity profile.

Tasks:

  • T8 First commodity entity profile (Claude session)
    • Pick: watermelon (Nathel’s most-handled commodity per ops)
    • Project from Taproot canonical data + Nathel events
    • Output: commodity_profile.watermelon.md in the tenant Taproot mirror
    • Operator agent can query it via get_entity_profile
    • Acceptance: querying the profile returns structured + markdown with at least 3 fact_citations sourced to real events
  • T9 End-W1 demo (you, 1 hour)
    • Walk through: real RP581 load → operator inspects → completed inspection appears in list → intranet shows inspection → agent queries commodity profile and cites it correctly
    • Record demo as the first agent_harness_session.<session_id> doc projection (eats own dogfood)
    • Acceptance: works end-to-end without manual data manipulation

End-W1 verification checklist (Friday afternoon):

  • RP581 ingest pipeline works for real loads
  • QC inspection workflow runnable end-to-end
  • At least 1 completed inspection in the system
  • Inspection list visible in tenant intranet
  • Doc projection pipeline ingests vault commits (against FIN Central vault)
  • Watermelon entity profile queryable by operator agent
  • Demo recorded

Stretch goal for Week 1 (if ahead of schedule):

  • Phase 5 FIN Central intranet bootstrap (intranet.fin.app live with partner-comms-ready content)

4. The Task DAG (Week 2)

                  T10 Onboard 3 inspectors + Alex (Mon-Tue)
                            │
                            ▼
            ┌─── T11 Comms system end-to-end testing
            │            │
            │            ▼
            │    T12 Real-world QC feedback loops
            │            │
            ▼            ▼
    T13 Doc pipeline   T14 Polish + bug fixes from real usage
        expand            │
            │             │
            ▼             │
    T15 More entity profiles (variety, vendor, region)
                          │
                          ▼
                  T16 End-W2 demo state

5. Day-by-Day Targets (Week 2)

Day 6 — Monday, 2026-05-25

Primary outcome: First production users onboarded.

Tasks:

  • T10 Onboard 3 inspectors + Alex Cohen
    • Inspectors receive: PWA login + 20-minute walkthrough + first test inspection completed under guidance
    • Alex receives: tenant admin access + intranet content review + intranet scoped-access verification
    • Each user becomes an actor in actors.memory with role + onboarding state recorded
  • T11 start Comms system end-to-end test
    • SMS inbound + outbound via Telnyx
    • Voice inbound (operator picks up via agent)
    • Email inbound to arrivals@, intel@
    • Each channel exercised by Alex + at least one inspector

Quality gates:

  • All 4 users authenticated and have completed first inspection
  • All 4 channels exchanged at least one message

Day 7 — Tuesday, 2026-05-26

Primary outcome: Real-world feedback loops active.

Tasks:

  • T11 continue Comms system testing
    • Exercise voice barge-in, SMS multi-turn, email reply chains
    • Document any latency or reliability issues
  • T12 First real-world QC feedback loop
    • Inspectors complete inspections on actual loads in flight
    • Bugs and friction surface immediately
    • Triage queue established
  • T13 start Doc projection pipeline against Nathel vault
    • Webhook from nathel-intranet repo wired
    • First test commits succeed
    • Inspection-related docs (per-inspector daily summary projection) flow

Quality gates:

  • Comms system test report drafted with any P0 issues
  • At least 3 real-world inspections completed by Day 7 EOD

Day 8 — Wednesday, 2026-05-27

Primary outcome: Doc projection delivers compound value.

Tasks:

  • T13 continue Doc projection pipeline
    • Daily arrivals summary projection ships
    • Vendor scorecard projection skeleton (will refine later)
    • Customer-facing customer profile projection skeleton
  • T14 start Polish from real-world usage
    • Address P0 bugs from T11/T12
    • Address friction points reported by inspectors

Parallel session option: T13 (build) and T14 (fix) are independent; run two sessions.

Day 9 — Thursday, 2026-05-28

Primary outcome: Multi-entity profiles + system maturity.

Tasks:

  • T15 Project additional entity profiles
    • One vendor profile (the most-shipped-from vendor at Nathel)
    • One region profile (Mexico in spring)
    • One variety profile (the most-handled variety this week)
    • Each profile cites at least 5 real events
    • Acceptance: operator agent’s hybrid retrieval blend can answer a representative question by composing across these profiles + live events
  • T14 continue Polish
    • All P0 issues closed
    • Open P1 issues triaged and assigned

Day 10 — Friday, 2026-05-29 — W2 DEMO STATE

Primary outcome: Programmable proof state.

Tasks:

  • T16 End-W2 demo
    • Walk through: real load → inspector flow → completed inspection → projected to intranet → entity profile updated → agent answer with citations → response to Alex’s question demonstrating “knows produce”
    • Record as another agent_harness_session projection
    • This is the first usable demo for Anthropic, investors, or federal pre-conversations

End-W2 verification checklist (Friday afternoon):

  • 3 inspectors + Alex actively using all systems
  • At least 20 real inspections completed
  • Comms system handles all 4 channels in production
  • At least 4 entity profiles published and citable by the agent
  • Tenant intranet is the daily-use surface for inspection review
  • Doc projection pipeline ingests both FIN Central and Nathel vaults
  • FIN Central intranet stretch goal: provisioned + seeded with canonical docs (if not done in W1)
  • At least 3 agent_harness_session projections recorded
  • Gradeboard score reflects the new entity-profile-augmented retrieval (A/B vs structured-only)

6. Parallel Agent Assignment Guide

To run sessions in parallel, structure each Claude/Codex prompt as:

TASK: [Task ID from this program, e.g. T2]
INPUTS: [paths to relevant specs, e.g. PROJECTION_CATALOG, PHASE_1_RUNBOOK]
EXPECTED OUTPUT: [acceptance criteria from this program]
DEPENDENCIES: [previous tasks that must be complete]
STOP CONDITIONS: [when to halt and escalate]
SESSION CONTRACT: cite-then-claim, structured outputs, doc projection
on completion

Two recommended parallel-friendly patterns:

Pattern A — “Two Lanes”: One Claude session on “build” track, one on “test/fix” track. The build session ships new functionality; the test session exercises it and reports issues. They alternate handoffs through git commits.

Pattern B — “Sequential with Daily Reset”: One agent at a time but each task is sized for a single session window. End-of-session emits a handoff doc that the next session reads to resume.

Pattern A is faster but riskier. Pattern B is safer for solo operation. Recommend B for Week 1 (foundation work) and A for Week 2 (parallel polish + onboarding).

7. Stop Conditions And Quality Gates

A task halts and escalates if:

  • Acceptance criteria can’t be met within 2 session windows
  • A dependency turns out to be incomplete
  • A test fails in a way that suggests architectural conflict
  • Data integrity at risk (production data being written incorrectly)
  • Token / cost budget exceeded for the session

When a task halts:

  1. Emit a task_halted event with reason
  2. Write a follow-up note in docs/programs/incidents/
  3. Surface in the daily standup doc projection
  4. Reassign or escalate

8. Continuous-Run Protocol

For the user running this with continuous parallel agent sessions:

  • Session journal: Every session ends with a agent_harness_session doc projection covering what was attempted, what shipped, what’s blocked, and what the next session should pick up.
  • Daily standup projection: Generated at end of each day, summarizing the day’s outcomes against this program.
  • Friday demo state: End of each week, produce a proof_package doc projection capturing the demo state. These accumulate as the Nathel proof ledger.
  • Token budget enforcement: Each session declares a max-spend threshold; halt and re-plan if exceeded.

9. Risks And Mitigations

RiskLikelihoodMitigation
RP581 extractor reveals unexpected format edge casesHighPad T2 with extra time; have Alex provide 5 diverse real PDFs upfront
Inspector PWA mobile-first issues (camera, offline)HighTest on real inspector phones Day 5; fix Day 6
QC workflow needs more states than initially modeledMediumState machine designed to be additive; new states are events
Comms system has Telnyx integration issuesMediumVerify Telnyx 10DLC is approved (per memory note); have fallback voice numbers
Doc projection pipeline performance at scaleLow2-week sprint volume is small; refactor later
Onboarding 3 inspectors at once exposes UX gapsMediumStage as 1-on-1-on-1, not 3-at-once if possible
Burnout (per Burnout Protection memo)MediumForce at least one full rest day across the 2 weeks; weekend boundary respected
Reservist duty conflictsLow-MediumConfirm no drill weekend conflict; if conflict, schedule program around it

10. What “Knows Produce” Means For This Sprint

The end-W1 acceptance criterion includes: agent “feels like it really knows produce.” Concrete test:

Ask the operator agent (after T8 ships): “We just got a load of seedless mini watermelons from Sonora. Walk me through what to check during QC and what defects to watch for at this time of year.”

Acceptance criteria for the agent’s response:

  • References the commodity profile by name (commodity:watermelon)
  • References the variety profile if it exists (variety:seedless-mini)
  • References the region profile (region:sonora-MX) or at least the season window (Mexican spring)
  • Cites at least 3 specific facts to events / knowledge rows (post-harvest temp, common defects, recent arrivals from this vendor)
  • Mentions any recent QC issues with this commodity at Nathel (from event projections)
  • Provides actionable next-steps grounded in handling SOPs

This response is structurally different from current agent answers (which would synthesize from chunks alone). It demonstrates the projection-layer-augmented reasoning the user has been building toward.

If the response can’t meet these criteria by end of W1, the entity profile pipeline isn’t ready — extend T8 into W2 and bring forward T14 polish.

11. End-State Definition

Friday 2026-05-29 EOD, the system is:

  • Operationally live at Nathel for QC inspections
  • Multi-channel for comms (SMS, voice, email, intranet)
  • Knowledge-enriched — agent reasons against entity profiles, not just chunks
  • Auditable — every inspection, every agent session, every projection is event-sourced and citable
  • Onboarded — 3 inspectors + Alex use it daily
  • Demonstrable — clean recorded demo for partners, investors, federal pre-conversations
  • Architectural — single platform, two deployments (FIN Central + Nathel), shared codebase, role-gated

This is the minimum viable proof state for the Nathel anchor + the foundation for everything in the Wave 2-4 roadmap.

12. Open Items Requiring Human Clarification

The following need confirmation from Rob before parallel execution starts:

IDItemDefault if no answer by Day 1
C-1Is RP581 a PP load receiving report? Need 3-5 sample PDFs from Alex.Assume yes; build extractor against samples.
C-2What are the 3 inspector identities? Names + roles + onboarding contact info.Defer to Day 6.
C-3What commodity is most-handled at Nathel right now for T8 entity profile?Default to watermelon based on prior context.
C-4Does Nathel have a separate GitHub org or do we use FIN’s?Use FIN org for v1; transfer later.
C-5Is Telnyx 10DLC approved? (Per memory: resubmitted 2026-04-17 with workaround.)Confirm before T11.
C-6Reservist drill schedule across May 18-29?Check now; reschedule program if conflict.

13. Companion Programs (Continuous)

While this 2-week program runs, the following continuous programs run in background:

  • Burnout Protection: explicit weekend boundary, daily session caps, one mandatory rest day in the program window
  • Doc Index Maintenance: new canonical docs added to the index as they emerge from sessions
  • Memory Hygiene: session-end memory writes capture learnings
  • Gradeboard Tracking: any agent quality change reflected in gradeboard
  • Federal Pipeline Background: SDVOSB consideration with counsel (low intensity)

14. The Daily Cycle

Each working day:

  1. Morning (15 min): Read the previous day’s standup projection. Identify carryover. Pick today’s primary task per the DAG.
  2. Working hours: Run agent sessions per the parallel pattern. Each session emits a journal projection.
  3. Mid-day (5 min): Quick check-in. Are you on track for the day’s target output?
  4. End of day (15 min): Run the daily standup projection. Confirm acceptance criteria for completed tasks. Note carryover for tomorrow.
  5. Friday afternoon (30-60 min): Run the W1 or W2 demo state projection. Update Nathel partners (Josh, Jake, Alex) with the demo recording.

15. References

Graph View