Responsible AI

instrument standards, not chatbot standards

Y0 acts on a person's working life — their documents, their calendar, their invoices — so we hold it to instrument standards, not chatbot standards. An instrument is predictable: the same input produces the same action, and when it cannot be predictable it must be inspectable. Our position is that responsibility is an architecture decision made before a feature ships, not a review board convened after it misbehaves. Consequential actions — sending, billing, committing — run on deterministic paths. Generative reasoning is confined to the parts of a task where being wrong is recoverable, and every output that touches the world carries a trace of how it got there. We do not claim this makes the system safe. It makes the system accountable, which is the property we can actually engineer today.

[ what we actually run ]

[01]

Deterministic paths for consequential actions

Any action that sends, spends, deletes, or commits runs on a hand-written code path the user can predict, never on a sampled model output. The model proposes; the deterministic layer disposes. If a consequential action cannot be expressed deterministically yet, it ships as a draft for human confirmation instead.

[02]

Reasoning traces on every run

Every Y0 run records which context was read, which model was routed, and which intermediate steps produced the result. The trace is stored with the run and shown to the user on request — 'why did you do that' is a button, not a support ticket.

[03]

The one-sentence test

Before a feature ships, we must be able to explain every data read it performs in one sentence a non-engineer would accept. Features that fail the test wait. This is enforced in spec review, before code exists, because it is much cheaper to fix there.

[04]

Capability ceilings per surface

Each product surface declares the maximum capability it may exercise — read-only, draft-only, or act-with-confirmation. The ceiling is enforced by the trust kernel, not by prompt instructions, so a confused model cannot talk its way past it.

[ open questions — honestly ]

Where exactly is the line between 'recoverable' and 'consequential'? Deleting a draft is recoverable; sending an email is not; renaming a file is somewhere in between, and our current taxonomy is a judgment call we revisit quarterly, not a theorem.
Confirmation fatigue is real: if we ask the user to approve too often, approval becomes a reflex and the safety property evaporates. We do not yet know how to measure when a confirmation stops being a decision.