Skip to content

Framework Differentiation

ORCA should be differentiated by the work it is built to support and the evidence it chooses to trust.

What ORCA Is Not

ORCA is not mainly:

  • a prompt library
  • a generic AI-agent wrapper
  • a note-taking layer with no delivery path
  • a collection of unrelated commands with no default workflow

What Actually Makes ORCA Different

It Treats Workflow As The Product

ORCA is built around the places real work breaks:

  • vague starts
  • missing specs
  • lost context between stages
  • skipped review and QA
  • no receipt for what happened
  • weak follow-up on blockers or next actions

It Stays Close To Real Operating Context

ORCA is designed for work that spans:

  • app shipping and release operations
  • research capture and staged promotion
  • blocker tracking and stale-work cleanup
  • mixed harness, repo, and tool environments

It Uses Stronger Sources Of Truth

ORCA is supposed to trust:

  • the vault when available
  • the repo and its artifacts
  • the declared system of record

before it falls back to generic outside advice.

It Teaches Without Becoming A Tutorial-Only Layer

ORCA is meant to onboard new users into orchestration while remaining a durable long-term operating surface.

That is different from systems that feel like a beginner wrapper before users graduate to something else.

Good Differentiation Language

Prefer language like:

  • durable workflow
  • inspectable execution
  • blocker-aware delivery
  • staged research to action flow
  • receipts, lineage, and review
  • one clear default path with deeper layers behind it

Bad Differentiation Language

Avoid language like:

  • revolutionary AI operating system
  • universal agent platform for every workflow
  • seamless autonomous intelligence layer
  • anything that sounds detached from the actual repo and vault evidence