Architecture

GigAI is two layers with a one-way dependency direction: a Gig imports GigAI core, and GigAI core is meant not to import a Gig. Today that is the rule the code is moving toward, not yet a fact: Scout ships in the same package as core, and core still imports some Scout modules (the gigai scout command groups in cli.py, run.py, default_init.py and a few others). Scout gets no special runtime treatment.

flowchart LR
  subgraph Core["GigAI core"]
    Config["Config and home"]
    Secrets["Secrets"]
    Targets["Model targets"]
    Adapters["Codex / Claude CLI adapters<br/>locked down: no tools, no local memories"]
    Life["Proposal and approval"]
    Journal["Journal and workpad"]
    Registry["Gig registry"]
  end
  subgraph Gig["A Gig (Scout today)"]
    Nodes["Goal graph and capabilities"]
  end
  Gig -- "imports" --> Core
  Core -. "today: some core modules still import Scout" .-> Gig
  Targets --> Adapters

The solid arrow is the direction Gigs are built for. The dotted one is the current state of the code: it is why the boundary is described as a direction and not as a guarantee.

Where things live

Path	Owner	What
src/gigai/	core	setup, config, journal, proposal/approval lifecycle, catalog, package boundary
src/gigai/scout/	Scout	find_jobs/ (acquire, assess, present), goal-graph data, ui/
~/.gigai/config.toml	core	settings, model targets, credential references (names, never values)
~/.gigai/scout/	Scout	the Scout project: find-jobs.json, resumes, the picked resumes

Model targets are covered in Model targets.