Skip to content

Friction Reduction Principle

The goal is to reduce friction, not create more setup work.

This is a framework-wide ORCA Framework policy, not a local preference for one feature area.

Core Rule

A tool, feature, integration, workflow, prompt, or automation should be surfaced, recommended, or required only when it removes more friction than it introduces.

What Friction Means Here

In ORCA Framework, friction includes:

  • setup burden
  • cognitive overload
  • repeated manual work
  • redundant tool decisions
  • docs confusion
  • workflow fragmentation
  • permission churn
  • integration sprawl
  • unnecessary prompts or questions
  • mode confusion
  • agent handoff confusion
  • maintenance burden
  • positioning drift that makes the framework sound generic instead of useful

What ORCA Framework Should Remove

ORCA Framework should make it easier to:

  • start without a teammate translating the system
  • follow one clear path through the first useful workflow
  • reuse what the user already has
  • keep state, evidence, and review artifacts in one place
  • support user-chosen tools without turning support into debate
  • hide advanced capability until it becomes relevant
  • help users improve over time without making them feel corrected
  • use subagents only when they reduce more confusion, context loss, or coordination cost than they create
  • use self-improvement only when it reduces more friction than it adds
  • require only the minimum install, plugin, and harness setup needed for the next real task
  • prefer check-only, staged, or prompt-first update behavior over silent disruption when auto-update risk is unclear
  • keep the README and top-level docs short enough that a new user can reach the right path quickly
  • describe the framework in language that matches real recurring work instead of generic AI-framework branding

What ORCA Framework Should Not Introduce Casually

Do not casually add:

  • required setup for optional value
  • broad recommendation menus when one path is enough
  • new integrations that exist only because they are possible
  • repeated clarification questions when strong context already exists
  • maintenance loops that produce more noise than signal
  • top-level copy that ignores stronger vault or repo evidence in favor of category fluff

Operating Consequences

  • supported does not mean shown by default
  • possible does not mean worth suggesting
  • optional must stay optional in the real workflow
  • advanced capability should usually be opt-in
  • direct help beats setup theater
  • use what the user already has before asking them to adopt something else
  • use the strongest live evidence before reaching for generic positioning language

Enforcement Surface

This principle should shape:

  • integrations and recommendations
  • paved roads
  • onboarding and docs
  • runtime adaptation and agent behavior
  • automation and maintenance loops
  • feature review for new framework additions
  • adaptive guidance and coaching surfaces
  • local and framework learning loops

Use: