Product
Product Definition
Fairway is the engineering control and accountability layer for agent-driven software delivery.
It keeps accountable intent, material decisions, evidence, independent judgment, and promotion state durable while coding agents and engineering tools perform the work. The result is a replaceable-provider workflow: a provider can stop, a context window can compact, or an orchestrator can change without turning chat history into the system of record.
Fairway is local-first. Its default product shape is one Go binary, one SQLite execution store, a CLI, and read-oriented dashboards. Coordination primitives such as sessions, checkpoints, handoffs, waits, notifications, lanes, and worktrees support the accountability model; they do not define the category.
Fairway also defines two complementary continuity capabilities. Its existing database-backed track memory keeps active execution resumable across provider replacement and context loss; legacy project-local memory files are migration inputs, not a second authority. Engineering knowledge maintains source-grounded, project-owned synthesis across tasks. Memory remains curated operating context; knowledge remains derived and non-canonical until promoted through normal documentation review. See Project working memory and Engineering knowledge.
Reusable rule packs add a separate operating-knowledge layer. Fairway core owns loading, matching, evidence expectations, and closeout readback; projects and domain packs own the rules themselves. Assurance profiles then map recorded facts into bounded readiness and evidence-gap reports without converting those reports into certification or approval. Proposed execution profiles, including the large-migration profile, compose these primitives but are not implemented runtime capabilities until their release notes say otherwise.
Fairway also treats governance as an observable engineering system. Delivery reports expose velocity and coordination overhead. Implemented advisory control-effectiveness analytics now measure coverage, control-specific signal, friction, and observable outcomes through the CLI and a read-only dashboard without claiming causality or granting policy authority. The first GPUaaS pilot validated the coverage-first suppression behavior and exposed adoption and instrumentation gaps; it did not claim incremental control effectiveness. See Control effectiveness and the GPUaaS pilot.
The Product Promise
For every bounded work item, a team should be able to determine:
- Intent: owner, scope, acceptance, risk, and current state.
- Decision: the material choice, alternatives, rationale, and cited facts.
- Evidence: commands and safe artifact references that support or contradict the current claim.
- Judgment: required review, recorded verdicts, and unresolved waits.
- Promotion: whether the work remains local and reversible or has satisfied the explicit controls for merge, release, deploy, or live execution.
Generated rationale, provider transcripts, and advisory recommendations may help a person reason. They are not provenance, approval, or risk acceptance.
Who It Is For
- Individual engineers using more than one coding-agent session.
- Small teams that need shared visibility without handing approval authority to a dashboard or orchestrator.
- Reviewers and operators who need to see missing evidence, stale work, and promotion blockers without reconstructing provider conversations.
- Platform teams that want a provider-neutral execution record alongside their existing source control, CI/CD, and planning systems.
Capability And Claim Inventory
These labels are mandatory in public and canonical Fairway documentation.
| Label | Meaning | Current Fairway examples |
|---|---|---|
| Implemented | Present in the current source and covered by repository validation. | Local CLI/SQLite store; tasks, sessions, checkpoints, decisions, evidence, handoffs, reviews, waits, notifications; versioned agent contracts; track memory; deterministic engineering-knowledge packets; local rule-pack matching; assurance evidence mapping and offline release packaging; workflow and merge-readiness checks; advisory control-effectiveness CLI/dashboard; read-oriented dashboards. |
| Validated practice | Used in a bounded real workflow with durable evidence, but not claimed as universal or externally certified. | Internal consumer provider replacement, memory/knowledge cold starts, review/release coordination, environment rehearsal, local shared-dashboard operation, and GPUaaS control-analytics data-quality calibration documented under docs/assessment/. |
| Experimental | Implemented as an explicit pilot or advisory surface and not the default authority path. | Shared-team server/write pilots, advisory provider narratives, notifier adapters, Postgres compatibility rehearsal, and prototype operating profiles. |
| Planned | Designed or tracked but not implemented as a supported runtime capability. | Migration execution profiles, a production Postgres runtime adapter, broad tracker API adapters, and a reviewed shared-team production deployment path. |
| Non-goal | Deliberately outside Fairway authority. | Autonomous approval, risk acceptance, merge, push, deploy, live mutation, credential custody, transcript-as-authority, or regulatory certification. |
The dated documentation inventory assigns every existing page a canonical or supporting role. Dated assessments are evidence inputs, not evergreen product authority.
How Fairway Fits
| System | Owns | Fairway contribution |
|---|---|---|
| Coding agent or IDE | Code generation, investigation, provider interaction | Bounded task packet, durable attachment, checkpoint, evidence, and handback state |
| Git and forge | Source history, branches, pull requests, remote collaboration | Worktree/branch posture, commit evidence, promotion and merge-readiness checks |
| CI/CD | Build, test, package, deploy, release execution | Monitor state, evidence references, failure routing, release/deploy preflight and handback |
| Issue tracker | Roadmap, stakeholder planning, backlog discussion | Import/link/export context while retaining execution truth in Fairway |
| Agent orchestrator | Provider scheduling and steering | Deterministic next actions, waits, packets, capability checks, and authority guards |
| Identity proxy | Authentication and access policy | Read-only/shared boundary metadata and fail-closed configuration; no replacement for the proxy |
Fairway composes with these systems. It does not claim to replace them.
Principles
- Accountability before automation. Every consequential action has a named actor, boundary, and evidence expectation.
- Evidence before assertion. Command results and safe artifacts support claims; generated summaries do not become proof by repetition.
- Independent judgment stays independent. Review routing and inheritance cannot silently waive live, production, security, release, credential, or public-exposure boundaries.
- Promotion is explicit. Local reversible work and remote or live action are different states with different controls.
- Deterministic state before advisory intelligence. Fairway computes routine next actions from durable facts before asking a model or person to interpret exceptions.
- Local-first by default. Core work requires no hosted Fairway service.
- Configurable policy, stable product grammar. Projects configure roles, profiles, routes, and gates without hardcoding one consumer taxonomy into core.
- Provider-neutral records. Provider sessions are replaceable attachments; the task, decision, evidence, and review record is durable.
- Progressive disclosure. A common reversible path stays short; advanced coordination and consequential gates appear when the work requires them.
- No hidden authority. A dashboard, adapter, watcher, recommendation, or notification does not silently gain approval, merge, deploy, or live-action authority.
Source Of Truth
Versioned backlog and profile files define intended task shape. The Fairway DB owns runtime claims, status, sessions, checkpoints, decisions, evidence, reviews, waits, handbacks, and notifications. Git, CI/CD, issue trackers, and provider systems remain authoritative for the facts they execute or host.
Fairway links those facts; it does not overwrite their ownership.
Direction
Current product work focuses on making the accountability chain easier to adopt, strengthening shared-team boundaries without abandoning local-first operation, and measuring whether specific controls discriminate useful outcomes at an acceptable cost. Coverage and observational limits remain visible; sparse data never becomes a reason to waive mandatory safety invariants.
The versioned product backlog records planned work. Release scope and implemented behavior are reported in release notes, not predicted here as dated version promises.
Non-Goals
Fairway is not a workflow/DAG engine, CI runner, issue tracker, IAM provider, LLM gateway, credential store, artifact signer, compliance certification system, or autonomous engineering manager. It does not silently claim, approve, merge, push, deploy, release, or mutate live environments.
The durable rules are in Product boundaries.