Constructs

EMBER has nine construct types. Each maps to a specific pipeline stage. One construct per .sil file.

SIGNAL

Produced by A-00. The pre-forage knowledge unit. One signal per known workflow — written before extraction begins. Signals are what the forage agent reads to orient itself before touching the system.

CONSTRUCT  signal
ID         cart.checkout
VERSION    1
─────────────────────────────────────────
type:      workflow
entry:     POST /cart/submit
entities:  Cart, Order, Payment, User
boundary:  Stripe, SendGrid, PostgreSQL
source:    route table, API docs
notes:     High abandonment reported at payment step

Fields

Field	Required	Description
type	yes	`workflow` / `background` / `integration`
entry	yes	known entry point — route, job name, event
entities	yes	business nouns this workflow touches
boundary	yes	external systems it talks to
source	yes	where this signal came from
notes	no	anything worth flagging before extraction starts

WORKFLOW

Produced by A-01. The server-side trace. One workflow per business process. Flow and I/O — nothing else.

CONSTRUCT  workflow
ID         cart.checkout
VERSION    1
─────────────────────────────────────────
entry:  POST /cart/submit
actor:  authenticated user

  validateCart(cartId, userId)
  calculateTotal(items, promoCode)
  chargePayment(total, method)      → Stripe
  createOrder(cartId, chargeId)     → DB write
  sendConfirmation(userId, orderId) → SendGrid

out:    orderId, 200 OK
error:  payment failure → 402, order not created

confidence:  high

Rules

Each line is one function call or one I/O operation
Boundary calls are marked with → SystemName
DB writes are marked with → DB write
DB reads are marked with → DB read
Keep function names as found in the source — do not rename
out is the success terminus
error covers known failure paths only

SCREEN

Produced by A-02. The UI layer trace. One file per workflow — all screens for that workflow in sequence. ASCII wireframes showing what the user sees and what they do to move forward.

CONSTRUCT  screen
ID         cart.checkout
VERSION    1
─────────────────────────────────────────
SCREEN 1 — Cart review
┌─────────────────────────────────────┐
│  Your Cart                          │
│  ─────────────────────────────────  │
│  [ ] Product name          $24.00   │
│  Promo code:  [______________]      │
│  Subtotal:                 $36.00   │
│  [Checkout →]                       │
└─────────────────────────────────────┘
on: "Checkout →" → SCREEN 2

SCREEN 2 — Shipping
┌─────────────────────────────────────┐
│  Name:    [________________]        │
│  Address: [________________]        │
│  Delivery: ( ) Standard             │
│            ( ) Express              │
│  [← Back]           [Continue →]   │
└─────────────────────────────────────┘
on: "Continue →" → SCREEN 3

SCREEN 3 — Payment
┌─────────────────────────────────────┐
│  Card:    [____________________]    │
│  Expiry:  [______]   CVV: [____]    │
│  [← Back]         [Place Order →]  │
└─────────────────────────────────────┘
on: "Place Order →" → SCREEN 4

SCREEN 4 — Confirmation
┌─────────────────────────────────────┐
│  Order Confirmed ✓                  │
│  Order #:  84921                    │
│  [Continue Shopping]                │
└─────────────────────────────────────┘
on: "Continue Shopping" → home

server:  workflows/cart.checkout.sil
mapping:
  SCREEN 1  →  display only
  SCREEN 2  →  validateCart(), calculateTotal()
  SCREEN 3  →  chargePayment(), createOrder()
  SCREEN 4  →  sendConfirmation() → result displayed

confidence:  high

Rules

Every screen has a label after the SCREEN N — marker
Every screen ends with one or more on: transitions
Inputs shown as [____], selects as ( ), checkboxes as [ ]
No styling, no colors, no component names — layout only
Screens in sequence top to bottom

SCREEN beyond UI — v0.1 note

SCREEN is currently defined for user-facing interfaces, but the construct is more general than its current scope suggests.

A screen is something you look through — or something that filters. Both meanings apply.

For background processes and integrations, SCREEN can represent the perspective layer — what the process examines, what it passes, what it rejects, what it flags. No UI required:

CONSTRUCT  screen
ID         order.fraud-check
VERSION    1
─────────────────────────────────────────
type:      background
examines:  order amount, velocity, location delta
passes:    orders below risk threshold
flags:     velocity > 3 orders / hour
rejects:   known fraud signatures
output:    risk score → order.checkout workflow

Same construct. Same question answered: what does this process examine, and what moves forward? This interpretation is under consideration for a future version of the spec.

SPEC

Produced by A-03. The semantic intent specification. One spec per workflow. Answers one question: what was this actually trying to accomplish?

This is the document the original system never had. It is what A-04 reads to choose the stack. It is what A-05 reads to build. It is what A-06 reads to certify.

CONSTRUCT  spec
ID         cart.checkout
VERSION    1
─────────────────────────────────────────
intent:
  Allow a customer to purchase items in their cart
  and receive order confirmation

journey:
  Cart review → Shipping → Payment → Confirmation

inputs:
  promoCode       optional
  address         required
  deliveryOption  required
  cardDetails     required

rules:
  - Promo applied before total calculated
  - Charge must succeed before order is created
  - Confirmation sent only on successful order
  - Guest checkout allowed — login not required

outputs:
  orderId
  confirmation to user via email

boundaries:
  Stripe    → payment processing
  SendGrid  → order confirmation email
  DB        → order record persistence

confidence:
  server:  high
  ui:      high
  spec:    high

gaps:
  - none

EPISODE

Written by any agent or human when a change occurs mid-engagement. The memory layer of the pipeline. Every subsequent agent reads open episodes before doing their work.

CONSTRUCT  episode
ID         ep-042
VERSION    1
─────────────────────────────────────────
date:     2026-03-15
trigger:  client requirement change
status:   open

change:
  Add guest checkout — purchase without login required

reason:
  Client data shows 40% cart abandonment at registration step

affects:
  A-01  → add guest.checkout workflow
  A-02  → add guest path screens to cart.checkout
  A-03  → update spec — guest vs authenticated intent
  A-05  → new UI pass and API route for guest flow
  A-06  → extend test coverage to include guest path

skip:
  A-00  → brief unchanged
  A-04  → stack unchanged

reference:
  stakeholder: Sarah Chen, Product Lead
  meeting:     2026-03-14 product review

Status values

Status	Meaning
`open`	change recorded, agents have not yet processed it
`active`	one or more agents currently working on it
`resolved`	all affected steps completed and verified

Episodes are never deleted. They are the audit trail.

ARCHITECTURE

Produced by A-04. The system-level design decision. One architecture per engagement — the single artifact that names the target stack, states the rationale, and captures any strategic constraints the Builder must honour.

CONSTRUCT  architecture
ID         wealth2track
VERSION    1
─────────────────────────────────────────
target:    React 18 + TypeScript (local-first, PWA)
rationale:
  Flutter/Firebase → browser-native eliminates app store dependency.
  Local-first with IndexedDB satisfies offline requirement.
  No backend — Firebase costs removed, privacy surface reduced.

constraints:
  - Must work offline — IndexedDB as primary store, sync on connect
  - No authentication changes — existing Firebase Auth retained
  - Budget ceiling: zero new infrastructure

risks:
  - IndexedDB sync conflict resolution not specified — flagged to A-05
  - PWA install prompt UX varies by browser

confidence:  high

Fields

Field	Required	Description
target	yes	Target stack — runtime, language, key libraries
rationale	yes	Why this stack — the reasoning A-04 applied
constraints	yes	Non-negotiable requirements the build must satisfy
risks	no	Known open questions for Builder or Certifier
confidence	yes	`high` / `medium` / `low`

BLUEPRINT

Produced by A-04. Layer-specific architecture detail. One blueprint per architectural concern — data model, API surface, auth flow, state management. Blueprints decompose the architecture decision into implementable layers.

CONSTRUCT  blueprint
ID         wealth2track.data
VERSION    1
─────────────────────────────────────────
layer:     data
concern:   local-first storage model

entities:
  Transaction   id, amount, category, date, note, syncedAt
  Category      id, name, colour, budgetLimit
  Account       id, name, currency, openingBalance

stores:
  transactions  indexed by (date), (category, date)
  categories    small table, full-scan acceptable
  accounts      single row per account, no index needed

sync:
  strategy:   last-write-wins on syncedAt timestamp
  conflict:   flag to UI — user resolves manually

boundaries:
  IndexedDB  →  primary store
  Firebase   →  sync target (write-through on connect)

confidence:  high

Rules

One blueprint per architectural layer or concern
ID follows <engagement>.<layer> naming
The layer field names the concern: data, api, auth, state, infra
Blueprint bodies are free-form — whatever the Builder needs to make implementable decisions

BUILD

Produced by A-05. The build pass record. One build per pass — what was implemented, what was skipped, what was discovered. Builds are the Builder's running log, not documentation.

CONSTRUCT  build
ID         wealth2track.pass-1
VERSION    1
─────────────────────────────────────────
pass:      1
scope:     data layer + core transaction CRUD

implemented:
  - IndexedDB schema — transactions, categories, accounts stores
  - TransactionStore service — add, update, delete, list by date range
  - CategoryStore service — CRUD, colour assignment
  - Seed data loader for initial categories

skipped:
  - Sync layer — deferred to pass-2, conflict strategy needs A-04 clarification
  - Import/export — not in A-03 spec, flagged as episode candidate

discovered:
  - IndexedDB migration path not specified in blueprint — added as ep-044
  - Category delete cascade requires transaction category nullification

confidence:  high

Fields

Field	Required	Description
pass	yes	Build pass number — increments per run
scope	yes	What this pass covered
implemented	yes	What was built — bullet list
skipped	no	Deferred items with reason
discovered	no	New findings — episodes written, gaps found
confidence	yes	Builder's confidence in what was produced

CERTIFICATION

Produced by A-06. The spec compliance result. One certification per engagement. Answers one question: does the built system do what the spec said it should do?

CONSTRUCT  certification
ID         wealth2track
VERSION    1
─────────────────────────────────────────
result:    certified

spec:      specs/cart.checkout.sil
build:     builds/wealth2track.pass-3.sil

verified:
  - All spec rules confirmed in implementation
  - Journey: Cart review → Shipping → Payment → Confirmation — complete
  - Charge before order created — verified
  - Promo applied before total — verified
  - Guest checkout path — verified (ep-042 resolved)

coverage:
  unit:         94%
  integration:  88%
  e2e:          cart.checkout golden path — passing

gaps:
  - Refund flow not in spec — not tested (out of scope, noted)

confidence:  high

Result values

Result	Meaning
`certified`	System matches spec — ready for handoff
`with-notes`	Matches spec but minor gaps noted — acceptable for handoff
`on-hold`	Fails one or more spec rules — Builder must address before handoff

Fields

Field	Required	Description
result	yes	`certified` / `with-notes` / `on-hold`
spec	yes	Path to the spec artifact being certified against
build	yes	Path to the final build artifact
verified	yes	List of verified spec requirements
coverage	yes	Test coverage summary
gaps	no	Anything out of scope or not verified — with reason
confidence	yes	Certifier's confidence in the result

Constructs ​

SIGNAL ​

WORKFLOW ​

SCREEN ​

SPEC ​

EPISODE ​

ARCHITECTURE ​

BLUEPRINT ​

BUILD ​

CERTIFICATION ​

Constructs

SIGNAL

WORKFLOW

SCREEN

SPEC

EPISODE

ARCHITECTURE

BLUEPRINT

BUILD

CERTIFICATION