> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bijection.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Quickstart
> From signing in to your first governed decision, in six steps.
This is the one customer path. It walks the six steps your workspace itself
tracks: it provisions an isolated environment, connects a source, publishes and
deploys a product, captures that source at an immutable basis, opens a
dashboard over it, and executes one Action that lands in the ledger.
Your workspace home shows exactly these six steps and derives each one from
evidence, not from a checklist you tick. Nothing here has to be repeated in the
product.
**What you need**
**Six steps**, and **four credentials** — no more.
1. **A Bijection account sign-in.** Browser SSO through your account's identity
organization. `eclipse login` uses it and stores an eight-hour bearer in your
operating-system credential vault.
2. **A payment method.** Creating an environment opens a hosted checkout.
Provisioning starts when that invoice is paid.
3. **Your source system's own credential.** A database URL, or an OAuth consent
you give the connector. It becomes an immutable secret version; you never
paste it into a file.
4. **A workspace sign-in.** Your isolated environment has its own identity
organization, separate from the account one. It signs you into the workspace
browser and into `atelier`.
You never hold a repository, signing, infrastructure, Kubernetes, or database
credential. Bijection owns those and never returns them.
```bash theme={null}
go install ./cmd/eclipse # or install the published `eclipse` release
```
## 1. Environment ready
Sign in, choose a region and plan, and create the environment. Creation is one
idempotent request that also opens the hosted checkout; the provisioning worker
converges the rest.
```bash theme={null}
eclipse login
eclipse whoami --json
eclipse environment catalog --json
eclipse environment create --name oversight --provider gcp \
--region europe-west9 --plan production --json
eclipse environment get --json
```
The environment is ready when `eclipse environment get` reports it active. It is
one isolated installation — its own database, storage, source plane, and
identity organization. There is no shared data plane and no tenant key.
## 2. Source connected
Clone the environment's product repository and scaffold a product in it. Git
authenticates with your Eclipse login through a hidden credential helper; there
is no second Git credential to manage.
```bash theme={null}
eclipse repository clone ./oversight-product
cd ./oversight-product
eclipse init .
```
Declare the connection and its source datasets in `data/connectors/*.star`, then
bind the credential. For a database, `eclipse secrets set` reads the value from
a hidden prompt and writes an immutable secret version plus its lock reference.
For an OAuth provider, `eclipse connector authorize` runs one loopback
authorization-code flow and does the same for all three references at once.
```bash theme={null}
eclipse secrets set warehouse_url # value from a hidden prompt
# or, for an OAuth provider:
eclipse connector authorize
# Discover the real tables before you declare datasets over them:
WAREHOUSE_URL=... eclipse source inspect postgres --url-env WAREHOUSE_URL --schema public
```
`source inspect` reads your database directly from the authoring machine and
reports which tables are usable and which need a declared logical key. The
workspace marks this step complete once an operator runs **Check health** on the
connection in **Data sources** — which needs the product deployed, so expect to
finish this step just after the next one.
## 3. Product validated
Compile the model, then publish it as one signed review branch. Merging that
branch publishes the product change; releasing and deploying selects it.
```bash theme={null}
eclipse model check .
eclipse model guide . # what each journey step still needs
# First product in an empty repository — the one direct write to main:
eclipse release --message "initialize product"
# Every change after that is a signed review branch:
eclipse draft create pricing-rules --repository .
eclipse draft submit --repository . --message "declare the pricing rules"
# review and merge that branch in Eclipse, then select it:
eclipse deployment create --product-release-id --json
```
`eclipse model guide` reports, for each of these same six steps, what the model
directory already declares and what it still needs. It is the authoring-side
view of the journey you are walking.
## 4. First capture
The deployment captures every declared dataset on its cadence and publishes one
immutable source transaction. Watch it land in the workspace under **Runs**, or
from the CLI:
```bash theme={null}
atelier login
atelier whoami
```
Every governed read from here on resolves at one published transaction. There is
no live or query-time source read to configure.
## 5. First dashboard
Open the workspace and go to **Dashboards**. A panel reads exactly one governed
function; the function reads the captured basis. Rendering one is the step —
there is nothing to wire up.
```bash theme={null}
atelier functions list
atelier functions run vendors_unbooked
atelier dashboards query wedding_plan
```
## 6. First decision
Plan first. A plan is stateless: it shows the exact effects and writes nothing.
Execution re-resolves the authoritative dataset transaction and refuses a stale
plan.
```bash theme={null}
atelier actions plan BookVendor --target V-1 --input comment='confirmed' > plan.json
atelier actions execute plan.json
atelier reviews list
atelier events tail
```
That last command is the point of the exercise. The decision is now an
append-only fact carrying the basis it read and the evidence it decided on, and
your workspace home reports the journey complete.
## Where to go next
The model directory is the whole production composition input.
Plan, review, execute — the only way the world changes.