Skip to content
facetfacet

Bootstrap a Workspace

Facet should arrive in a workspace as a commission, not an installer. There is no runtime to add and no generic truth engine to scaffold. The Peer first reads the product as it exists, the operator reviews that account, and only then does the pair change the office or the product.

This page is designed to be handed directly to a colleague and their AI Peer. For an existing product, copy the commission below. For a new product whose fit has already been established, copy the AGENTS.md seed.

The shortest handoff is:

Read https://facet.kinra.ai/building/bootstrap-a-workspace/ and follow the Existing Workspace Commission. Inspect first; make no workspace change until I have reviewed your account of the product.

Before Either Path

Section titled “Before Either Path”

Facet fits only when all three conditions are real:

  1. there is durable shared truth whose sources can be incomplete, overlapping, or in conflict;
  2. consequential judgment and provenance matter; and
  3. a human–AI pair will actually remain present inside the product.

If the work is stable and deterministic, use a script or ordinary application. If there is no durable truth to govern, there is no mass. If no operating pair will be home, thin surfaces become abandoned cuts. The bootstrap must be able to return Facet does not fit without treating that result as failure.

Existing Workspace Commission

Section titled “Existing Workspace Commission”

Paste this into the Peer that already works with the product. The first pass is read-only because an existing workspace contains product facts and local instructions that a generic doctrine cannot safely replace.

You are being commissioned to assess this product for adoption of the Facet
doctrine.


Read before reasoning:


1. Every applicable local AGENTS.md and the product's current concept, status,
   architecture, decision, operating, and verification documents.
2. https://facet.kinra.ai/the-facet/
3. https://facet.kinra.ai/understanding/the-mass/
4. https://facet.kinra.ai/understanding/the-rails/
5. https://facet.kinra.ai/building/the-peer-workspace/


Phase one is inspection only. Do not edit files, rename components, add a
runtime, scaffold a schema, delete a surface, migrate records, or call the
product a truth machine. Existing product and customer facts outrank the
template. Mark unknowns as unknown and distinguish direct observation from
inference.


Return one adoption brief in the conversation with these sections:


1. Fit
   - State Fit, Partial fit, or Does not fit.
   - Give the observed durable truth, consequential judgment, and operating
     presence that support the verdict.


2. The operating pair
   - Name the human operator, the AI Peer's current harness, and what makes
     their working relationship durable beyond this session.
   - Name every relevant person outside the bond. Do not infer a facet merely
     because a role exists.


3. The current truth loop
   - Name the smallest coherence boundary across which a local answer could
     create a hidden collision.
   - Inventory evidence sources, original preservation, provenance, and each
     source's bounded authority.
   - Identify what the product currently treats as truth, how it changes, what
     review binds, and whether current values retain ancestry and uncertainty.
   - Keep evidence, contributions, current truth, changes, and publications
     distinct in the report even if the implementation currently collapses
     them.


4. The rails already present
   - Inventory deterministic reads, typed operations, invariants, concurrency
     boundaries, approval gates, append-only records, verification, recovery,
     and degradation behavior.
   - For every claimed rail, cite the concrete local mechanism. A written rule
     that depends on careful memory is a gap, not a rail.


5. Surfaces and channels
   - For each existing surface, name who actually uses it, what fact or ask it
     carries, what it collects, and whether it owns parallel truth.
   - Name existing channels such as email, calls, files, or business systems
     through which encounters already occur.
   - Flag operator surfaces, facet creep, and the portal reflex as questions to
     investigate, not automatic deletion orders.
   - Test whether the mass would survive each surface being ignored, shared,
     recut, or removed.


6. Contradictions, costs, and unearned claims
   - Put contradictory documents or implementations first.
   - Name observed failures and their costs. Do not invent a grave for a
     hypothetical failure.
   - List every Facet property the product cannot yet claim mechanically.


7. Smallest adoption sequence
   - Propose the smallest reversible change that addresses one paid-for
     tension in the current product.
   - Preserve existing behavior, authority, and outside channels unless the
     operator explicitly reviews their change.
   - Separate workspace changes, mass changes, rail changes, and facet changes.
   - State how each step will be verified and what evidence would cause the
     pair to reverse it.


8. Proposed workspace instructions
   - Draft the product-specific additions or amendments its AGENTS.md needs.
   - Point to existing authoritative documents instead of duplicating them.
   - Preserve applicable local and nested instructions.
   - Do not apply the draft yet.


End by asking the operator to correct the observed account and approve, amend,
or reject the first change. Make no workspace mutation until that review.

The operator’s review is part of the commission, not ceremony after it. A plausible map of authority is still only a model-produced claim until the person who holds that authority corrects it. Once reviewed, preserve accepted facts in the product’s existing canonical documents and merge the tailored instructions into its current AGENTS.md; do not leave the adoption brief as a parallel product description.

Choose the First Paid Seam

Section titled “Choose the First Paid Seam”

An adoption plan should begin where the current product already hurts. Flow’s first useful workspace change was a governed read path because the Peer was reconstructing the account repeatedly. Its first rails came from evidence that could be misread, changes that could go stale, and approvals that needed to bind exact proposals. Its operator surface died only after its capabilities had another home.

Those are examples from one stone, not a prescribed order. Another product may first need to preserve original evidence, distinguish a publication from its sent state, name a coherence boundary, or stop an outside form from editing truth directly. Choose the tension reality has already exposed. Do not build a complete-looking mass in anticipation of future use.

The same restraint applies to facets. An outside person may keep using email, a spreadsheet, a call, or an existing system while the pair learns the encounter. Cut only when a repeated boundary deserves an excellent deliberate path. The mass must admit evidence safely either way.

New Workspace AGENTS.md

Section titled “New Workspace AGENTS.md”

For a new product that passed the fit test, use the following as a seed. Replace every placeholder with a reviewed fact or the word unknown. The template creates questions and operating discipline; it cannot supply domain truth.

# Working in <product>


<Product> is being built under the Facet doctrine: one living mass, inhabited
by the operating pair, with thin cuts where the bond ends. This repository is
the pair's durable office, not merely source control.


Facet is an operating doctrine here, not proof. Do not call this product a
truth machine or claim a rail, facet, encounter, or product outcome until the
implemented record supports it.


## Read before acting


- Read `<product concept>`, `<current status>`, and the domain documents that
  govern the work in scope.
- Read https://facet.kinra.ai/the-facet/ and the linked working reference.
- Read deeper local `AGENTS.md` files before entering the areas they govern.


When documents disagree, stop the affected change and surface the
contradiction. Existing product and customer facts must be preserved exactly;
never invent a fact to complete this template or satisfy validation.


## Product declarations


Keep these declarations current in their authoritative local documents:


- Operator: <human half of the pair>
- Peer and harness: <AI office and working environment>
- Coherence boundary: <smallest whole across which truth must change together>
- Evidence sources: <sources, original preservation, and bounded authority>
- Current truth: <what may be acted on now and where it is read>
- Consequential transitions: <what can advance truth and atomically record why>
- Human judgment gates: <decisions, authorship, and publication authority>
- People outside the bond: <actual people or roles, not imagined users>
- Facets: <implemented cuts, their person and purpose, or none>
- Degradation promise: <what remains true and usable without the Peer>


Unknown is a valid declaration. Fluency is not authority to fill a gap.


## Evidence and truth


- Treat every outside arrival as evidence until a declared, reviewed transition
  advances current truth.
- Preserve originals and provenance; extraction and interpretation are
  derivative and never rewrite their source.
- Bound each source's authority to what it can establish. Importance, storage
  location, model confidence, and recency do not expand that authority.
- Keep evidence, contributions, current truth, changes, and publications
  semantically distinct even if they share storage.
- Make consequential proposals as exact deltas carrying before, after, cited
  evidence, rationale, uncertainty, actor, and expected state.
- Bind approval to the exact proposal. Stale, invalid, or partially applicable
  work advances nothing and remains available for review.
- Preserve field-level ancestry and append the decision with the truth it
  advances.
- Keep generated, approved, sent, acknowledged, and incorporated distinct.


## The pair and the rails


- The operator works inside the mass with the Peer and receives no facet.
- Give the Peer governed reads over current truth, evidence, provenance,
  changes, obligations, and pending work. Do not reconstruct product meaning
  by grepping storage when a declared read exists.
- Carry machine values and their human meaning together. Name absence,
  uncertainty, suppression, and source status explicitly.
- Route consequential writes through typed operations and the same authority
  gates regardless of whether the work began with the operator, Peer, service,
  or outside contribution.
- Prefer structural impossibility to a rule that relies on everyone remembering
  to be careful.
- Keep context, decisions, graves, tool contracts, status, and recovery paths
  durable. Conversation history and model memory are not product state.


## Cuts and channels


- Cut a facet only for a real person outside the bond and a boundary need that
  has become clear through use.
- A facet shows reviewed fact, a labelled source observation, or an ask authored
  under declared authority. It owns no authoritative domain state and performs
  no reconciliation.
- Outside contributions enter as evidence and never edit current truth
  directly.
- A facet is an offered path, not an admission gate. Existing channels remain
  valid when their arrivals can enter through the same evidence discipline.
- The mass must survive a cut being ignored, shared, changed, or deleted. When
  deleting one, preserve the underlying capability and record the corpse and
  its cost.
- Treat facet creep and the portal reflex as defects to investigate. Do not hand
  people outside the bond open-ended chat and call it a facet.


## Progressive formalization


- Explore new judgment conversationally inside the mass from safe primitives.
- Capture repeated reasoning as a durable skill or workflow.
- Add a deterministic read or typed command when repeated mechanical labour or
  consequential authority requires it.
- Cut a facet when a repeated outside encounter deserves a focused product
  surface.
- Promote observed hindsight, never anticipated possibility. Promotion moves
  labour, not authority.


## Verification and honesty


- Run the product's declared checks before handing off a change and report what
  was not verified.
- Preserve the last valid truth and every completed decision when work fails or
  the Peer is unavailable.
- Keep observed reality, proposals, open questions, local heuristics, and
  unearned claims visibly separate.
- Doctrine follows reality. Keep implementation in this product; bring a lesson
  back to Facet only after this stone has paid for it, with its tension and
  evidence boundary intact.

What the Template Does Not Do

Section titled “What the Template Does Not Do”

The seed does not choose a database, repository layout, model, harness, command framework, schema, approval policy, or facet. Those are product decisions. It also does not authorize a Peer to rewrite an existing AGENTS.md; merge and reconcile local instructions under human review.

A copied template is not a second proving implementation. The test begins when another operating pair uses the office against real evidence, finds where this commission is wrong or incomplete, and records what the product paid to learn. That correction is the useful return path to Facet.