Public Ideas, Private Code

Spillway is unusually public about its ideas while keeping its source repository private.

That distinction is deliberate.

The project publishes product philosophy, architecture explanations, scientific reasoning, privacy commitments, design tradeoffs, and development methodology so people can understand how the system is intended to work and why important choices were made.

The implementation repository, pull requests, internal issues, and release engineering remain private.

Why publish the ideas?

Trust is easier when a project explains its assumptions instead of presenting only polished product claims.

Spillway makes consequential choices about privacy, AI authority, evidence, synchronization, learning, recovery, and attention. Those choices are worth describing in public even when the source code itself is not public.

Public documentation also creates useful pressure to keep the architecture coherent enough to explain.

Human-directed AI collaboration

Spillway makes extensive use of AI for implementation, review, testing, exploration, and documentation.

AI can propose, criticize, and materially improve a design, but it does not independently set product direction or authorize major architecture.

Many decisions emerge through repeated human–AI iteration. Important architectural decisions remain human-directed.

Documentation Provenance separately explains how public pages describe human and AI contributions to the writing itself.

Explain the decision before hiding it in code

For consequential features, the project tries to write down the problem, intended behavior, and important boundaries before implementation begins.

This matters especially for privacy, identity, synchronization, recovery, authority, and data lifecycle. A written design gives later work something concrete to preserve or deliberately revise.

Prefer small, reviewable changes

The project favors bounded changes with a clear purpose and a defined stopping point.

That makes defects easier to isolate and makes independent review more useful.

Design for mistakes and interruptions

Software fails. Computers restart. Networks disappear. People change their minds.

Recovery, retry semantics, rollback, and correction are treated as part of feature design rather than cleanup to add later.

Use independent review for important claims

Consequential work often receives challenge-oriented review aimed at finding incorrect assumptions, missing cases, unsafe behavior, or claims the implementation does not support.

The goal is not ceremony. It is to make important mistakes easier to discover before they become permanent architecture.

Human control is an engineering rule

Human decisions should remain distinguishable from automated suggestions.

Important actions should be visible and correctable. Where a feature depends on inference, the system should preserve enough provenance to explain what was observed, what was inferred, and what the user actually decided.

From Data to Knowledge · Explainable AI

Privacy is a design constraint

Where practical, Spillway prefers architectures in which the project operator never receives sensitive user information at all.

New data paths should be explicit. Optional transmission should require informed choice. A change in ownership or stewardship should never silently create permission for new access to user data.

The binding public commitments live in the Privacy Policy and Terms of Service.

Public documentation is not a changelog

Most public pages describe what Spillway is designed to do rather than narrating each implementation step.

Current availability, beta limitations, and testing expectations live on a small number of status-oriented pages. The rest of the site aims to explain durable product ideas in language that remains useful as the implementation changes.

Licensing and stewardship

Private repository access does not grant permission to copy, modify, redistribute, sublicense, create derivative works, or use the code commercially unless a separate written license expressly allows it.

The long-term organizational and licensing model may evolve. Material changes that affect privacy, control, or data flows should be explained clearly.

Documentation provenance: Iterative human–AI construction. See Documentation Provenance.