Skip to content

Vault-Derived Positioning

This note captures the evidence used to keep ORCA positioning grounded in actual work instead of generic framework language.

Evidence Themes

1. Real Delivery And Release Work

Vault evidence shows recurring work around shipping apps, not just prototyping:

  • Fastlane and TestFlight blockers across Scoutly, Scoutly Tasks, WordRush, and Cardinal
  • App Review and release queue concerns
  • deployment follow-up like DNS and Vercel domain setup

This means ORCA should describe itself as useful for execution, delivery, and follow-through, not only for idea generation.

2. Research Is Triaged, Not Just Collected

Vault evidence shows research notes being staged, promoted, or left parked based on actual lane relevance.

Examples from the vault include:

  • staged research notes that stay staged unless they connect to an active lane
  • technical research around SwiftUI, Swift 6 concurrency, Supabase, and App Store operations
  • repeated audit notes that separate useful findings from noise

This means ORCA should describe research as part of an operating workflow, not as generic knowledge management.

3. Blockers And Next Actions Matter

Vault evidence repeatedly captures explicit blockers and concrete next actions.

Examples include:

  • missing Fastlane credentials blocking release throughput
  • DNS work needed to finish deployment
  • schema drift or codebase-maturity follow-up items
  • stale projects where the next move is unclear and needs to be made explicit

This means ORCA should emphasize clarity, receipts, blockers, and next actions.

4. Mixed Tool And Runtime Reality

The vault reflects real work across repos, app stacks, release systems, vault notes, and automation surfaces.

That means ORCA should not pretend one host, one repo, or one prompt thread is enough context by default.

5. Operator Style Is Explicit

The operating-manual note is direct about execution preferences:

  • precision over politeness
  • structure over vibes
  • actionable output over explanation
  • shipping over theorizing

This does not mean the README should become personal. It does mean the framework voice should stay concrete and operational.

Positioning Consequences

The README and intro docs should:

  • describe ORCA as an operating framework for real software work
  • mention delivery, blocker handling, research triage, and coordination
  • stay grounded in durable workflow surfaces like specs, receipts, lineage, and review
  • avoid generic claims about transforming all knowledge work

What To Avoid

Avoid README language that sounds like:

  • a generic AI-agent manifesto
  • a founder story or autobiography
  • a prompt library with inflated orchestration language
  • a note-taking tool with no execution path