Product Boundaries

Fairway is the local, harness-neutral coordination and engineering-record layer for agent-driven delivery. It keeps task and worktree ownership, execution attachments, material decisions, evidence, independent judgment, and promotion state explicit while coding runtimes and external engineering systems perform the work.

Coordination is a Fairway capability, not a transfer of authority. Sessions, lanes, handoffs, waits, notifications, dashboards, and orchestrators can make work visible and resumable. They do not become approval, risk acceptance, merge, deploy, release, credential, or live-operation authority.

This page is the canonical product boundary. Other docs link here instead of restating or weakening it.

Boundary With Coding Runtimes And Seaway

Fairway's durable unit is a task and its cross-system engineering record. A coding harness or runtime owns an individual run. Seaway is a separately scoped optional runtime product intended to normalize and bound one such run; Fairway does not require it, and Seaway must remain usable by callers that do not use Fairway.

Boundary	Fairway owns	Runtime or optional Seaway owns
Identity	Task, lane, role, worktree assignment, session attachment, review, and promotion correlation	Run, attempt, runtime, provider/model, execution environment, and caller correlation
State	Task lifecycle, waits, checkpoints, handbacks, evidence coverage, review state, and readiness	Admission, effective run configuration, lifecycle events, cancellation, reconnect, and terminal result
Policy	Evidence expectations, review domains, workflow guards, and promotion boundaries	Tool, command, path, credential, network, data-egress, provider/model, resource, and run-budget controls
Output	Cited links across decisions, runs, commits, CI, reviews, outcomes, and external authorities	Ordered run events plus artifact, evidence, usage, cost, policy-decision, and failure facts

These invariants prevent authority or state from leaking across the boundary:

• a Fairway task may correlate with zero, one, or many runs;
• run success, failure, cancellation, or timeout never silently completes, blocks, or closes a Fairway task;
• a run-time approval permits only the named run operation and never satisfies a Fairway review domain or promotion gate;
• Fairway links runtime facts with their original source and uncertainty rather than rewriting them as Fairway-generated proof;
• Fairway coordinates durable lane worktrees, while a runtime may establish a disposable execution workspace within its declared run boundary; and
• unavailable or degraded runtime integration remains visible and does not prevent Fairway from coordinating another execution surface.

Any future Seaway adapter is an edge contract. It may map correlation IDs, capabilities, lifecycle events, terminal results, evidence references, usage, and cost facts. It must not merge the two state machines or convert advisory runtime output into task status, independent review, risk acceptance, or promotion authority.

Responsibility And Authority

Surface	May do	Must not imply
CLI and store	Record explicit task, decision, evidence, review, and promotion facts	That recording a claim proves or approves it
Dashboard	Read and explain current Fairway state	Privileged approval, send, merge, deploy, or live authority
Coordinator and watchers	Compute deterministic waits, reminders, and bounded next actions	Autonomous ownership transfer or consequential execution
Provider adapter	Attach a provider session and report bounded metadata or delivery proof	That provider output is provenance, approval, or policy
Reviewer	Record an attributable verdict within configured scope	Authority outside the review domain or over external systems
Human operator	Execute explicitly authorized external action and record evidence	That Fairway itself performed or authorized the action

Fairway Will Do

• Track tasks, ownership, state transitions, evidence, handoffs, reviews, sessions, watchers, worktrees, batches, and closeout.
• Surface stale, unsafe, review-gated, approval-gated, utility-gated, or incomplete work.
• Serve a shared read-only dashboard suitable for exposure through an identity-aware proxy or tunnel.
• Recommend next actions through CLI reports, dashboard diagnostics, and dry-run controller plans.
• Record provider-neutral usage metadata when an adapter supplies it.
• Record supply-chain provenance metadata that links tasks, sessions, checkpoints, evidence, reviews, commits, release verification, and safe artifact references without becoming a compiler/runtime dependency.
• Coordinate deterministic utilities such as CI monitors, codegen drift checks, release asset checks, and registry freshness checks.
• Integrate with planning systems such as Plane, Jira, Linear, and GitHub Issues while keeping local execution state in Fairway.

Fairway Will Not Do

• Auto-claim ready tasks or silently transfer ownership between lanes.
• Auto-approve reviews or waive required review domains.
• Auto-merge branches or auto-push commits.
• Auto-delete local branches, worktrees, or task state without an explicit operator command.
• Perform destructive, production-impacting, credential, or approval-gated actions without an explicit stop condition and operator decision.
• Become a CI runner. Fairway records CI evidence and monitor handbacks; CI systems still execute CI.
• Become an IAM or public web gateway. Shared dashboard mode blocks writes, but the user/project owns domains, identity providers, Access policies, tunnels, and JWT/header verification.
• Become a workflow/DAG engine. Fairway coordinates human-paced engineering lanes; it does not replace Temporal, Cadence, Argo Workflows, or similar systems.
• Become a coding harness or agent runtime. Fairway does not own the model/tool loop, select an effective provider or model for a run, sandbox execution, inject credentials, enforce run-time filesystem or network access, or police data egress.
• Replace external planning tools. Plane, Jira, Linear, and GitHub Issues can mirror roadmap or stakeholder context; they do not own Fairway execution state.
• Become an LLM provider abstraction. Fairway records sessions and usage metadata supplied by adapters; providers remain external.
• Become a compiler, package manager, artifact signer, SBOM system, attestation authority, or runtime dependency. Fairway may export provenance metadata for those systems to reference, but source/build/release integrity remains with the project supply-chain tooling.
• Store prompts, transcripts, secrets, provider credentials, or private auth material by default.
• Gate task completion on token cost, provider spend, or model choice. Usage accounting is an operational planning signal, not a completion gate.
• Encode one project's taxonomy as core product grammar. Prefixes such as CI-FIX-*, CD-FIX-*, UAT-BUG-*, OPS-FIX-*, HARNESS-FIX-*, or DOC-FIX-* belong to workstream profiles and project conventions. Fairway may surface or recommend them when a profile/adapter uses that taxonomy, but the prefix itself does not own status, review, evidence, or release semantics.

Controller Rule

The orchestration controller is advisory by default. It may classify state, recommend actions, start explicitly configured utility monitors, and emit provider continuation prompts when judgment is needed.

It must not silently claim, approve, merge, delete, push, deploy, or mutate production-impacting state. Any future apply path must name the exact mutation, show the dry-run plan, and keep stop conditions visible.

Structured advisory recommendations must pass fairway advisory validate before they are recorded or used for handoff context. Validation checks the action enum, target role, confidence, risk flags, cited Fairway facts, and provider wake routability warnings. Accepted recommendations may be recorded as advisory-recommendation evidence only; they do not approve reviews, accept risk, claim tasks, merge, push, deploy, run live actions, or mutate environments.

Usage Accounting Rule

Provider usage records are for planning and retrospection:

• which provider or model was expensive,
• which task shapes consume more tokens,
• which work should be moved to deterministic utilities,
• which workflows should be batched.

Usage records must not include prompts, transcripts, secrets, or provider auth material. Fairway may report counts, phases, roles, task IDs, provider names, confidence, and source metadata.

Provenance Rule

Fairway provenance is metadata and linkage, not content capture. Provenance exports may include task IDs, state history, checkpoint summaries, evidence references, review verdicts, session lifecycle, provider usage counts, commit SHAs, release tags, and verification outcomes. They must not include raw secrets, provider auth state, raw prompt bodies by default, private transcripts, raw tool bodies, or generated-content dumps.

See supply-chain-provenance.md for the model.

Adapter Rule

Adapters are edge contracts. Core Fairway remains provider-neutral.

• Provider adapters attach agent sessions and optional usage metadata.
• Utility adapters attach deterministic work such as CI polling.
• Tracker adapters mirror planning context to or from external issue trackers.
• Advisory provider adapters may be declared in config as bounded recommendation sources. They are metadata and validation inputs only; they do not make Fairway an LLM provider abstraction or grant execution authority.

Adapters may feed Fairway evidence, sessions, checkpoints, usage, and links. They do not decide task status, review approval, merge readiness, or release promotion on their own.

An optional Seaway adapter follows the same rule. Seaway run admission, approval, cancellation, events, results, and cost records remain run-level facts. Fairway may correlate and report them but does not inherit Seaway's execution authority, and Seaway does not inherit Fairway's coordination or promotion authority.

Provider thread steering is also an adapter boundary. Fairway may record that a handoff was recorded, a notification was delivered, or a provider thread was actually steered, but only the active provider/app surface can prove the direct thread capability existed. If a session does not expose tools such as send_message_to_thread and read_thread, agents must record Fairway state and route the manual relay through the coordinator/control track. A delivered or steered notification is a resume signal, not authority to approve, merge, push, deploy, release, or close work. For review-gated tasks, handoff-only or failed notification state is treated as notification-blocked rather than proof that a reviewer is actively waiting.