Sources, Capture, and freezing
On the product lifecycle rail, Sources comes before Capture, followed by Report. During Sources, you assemble and review the evidence boundary. Freezing permanently locks that source set. Only then does the Capture phase begin its knowledge-processing stages.
The Sources phase is where you add, prepare, preview, annotate, and freeze evidence. Capture processing starts from that frozen snapshot. Labels, actions, and layout may vary by release.
| Term | Meaning | Operational consequence |
|---|---|---|
| Sources phase | The preparation stage for repositories, files, connected databases, and attributed human knowledge | Review, preview, annotate, and freeze the complete evidence boundary before Capture processing |
| Freeze | A permanent lock of the prepared source set | You cannot add, remove, or replace sources after freezing |
| Capture phase | The knowledge-processing phase for one frozen scope and source state | Runs Survey, Plan, Extract, Discover, Infer, and Ask against the frozen evidence |
| Report | The asset-reporting phase that follows Capture | Presents durable knowledge outcomes when the corresponding report capability is available |
Source types and current connectors
| Source path | What it accepts | Current behaviour |
|---|---|---|
| Local files | Repositories, folders, documents, and other approved local files | Read and prepared in place; copied into the capture boundary only when you freeze |
| Connected systems | PostgreSQL, MongoDB, or Oracle | Connected read-only; browse the available structure, select an approved scope, and optionally include bounded samples |
| Tacit knowledge | Attributed Markdown notes | Preserves decisions, context, ownership, and operational knowledge that system artefacts do not contain |
The three connected-system connector families exposed today are PostgreSQL, MongoDB, and Oracle. The generic Connected systems label does not imply that other databases, APIs, or runtime connectors are currently available. Labels, actions, and layout may vary by release.
The executable lifecycle
A completed capture follows Survey → Plan → Extract → Discover → Infer → Ask. Discover and Infer are separate processing stages even when the current Beta interface groups them under one Discover & Infer tab. Ask is read-only and can become available once baseline claims exist; you do not have to wait for every higher-order surface to finish before asking a bounded question.
| Stage | Purpose | Durable result |
|---|---|---|
| Survey | Measure what was supplied | Source registry, inventory, attestations, structure and technology signals, coverage boundary |
| Plan | Turn the surveyed estate into a safe work sequence | Per-source work queue, dependencies, budgets, safety contract |
| Extract | Create deterministic facts and validated interpretations | Declared structures, per-source knowledge documents, canonical claims, citations, and known unknowns |
| Discover | Read across every extracted source at once | Higher-order surfaces such as call chains, shared data, cross-repository flows, controls, and change seams |
| Infer | Derive deeper candidate knowledge from each discovered surface | Evidence-linked node and edge candidates that remain explicitly marked as inferred |
| Ask | Query captured knowledge without changing it | Cited answers, explicit scope limits, known unknowns |
The current Beta view groups Discover and Infer while retaining per-dimension surface counts, inference progress, knowledge health, and the distinction between inferred and directly verified evidence. Labels, actions, and layout may vary by release.
Dimensions, surfaces, and lenses
These terms describe three different levels of organisation. A dimension is a fixed knowledge category. A surface is one concrete detected item inside a dimension. A lens is only a UI grouping used to filter dimensions.
| Concept | Example | What it is not |
|---|---|---|
| Dimension | call-chain or security-posture | Not a promise that every capture contains useful content in all 21 categories |
| Surface | A specific payment retry call chain | Not another name for a dimension |
| Lens | Security or Change & risk | Not an engine concept and does not change stored knowledge |
The current UI lenses are Structure, Integration, Reliability, Security, Change & risk, and Other. All removes the filter. Lenses change only what you see; they do not add, remove, or reclassify stored knowledge.
SOCK evaluates a fixed internal catalogue of 21 dimensions, from as-is-archaeology and business-rules through dependency-blast-radius, migration-seams, security-posture, and ui-flow. A capture can legitimately have zero surfaces in a dimension. See the [complete 21-dimension glossary](/sock/reference#dimensions) for the purpose and review question for every identifier.
Claims, evidence tiers, and honesty
Every accepted fact is retained as a claim traceable to its source. The system keeps how a claim was obtained visible: a parsed declaration, a live observation, an AI interpretation, or a human report are not equally strong.
- AI components propose interpretations; validated application code writes the canonical record.
- The model cannot promote its own output to a stronger evidence tier.
- A human report remains attributed and cannot outrank a parsed declaration.
- Missing, unexamined, unsupported, and unknown are distinct states.
- Evidence-backed does not mean infallible; consequential decisions still require source review.
Preview opens the generated artefact set without changing it. Evidence views connect each claim to a citation, evidence tier, and validation status; Known Unknowns records what the capture could not establish. Labels, actions, and layout may vary by release.
Preview, annotations, and tacit knowledge
| Capability | Use it for | Evidence effect |
|---|---|---|
| Preview | Inspect frozen inputs or generated knowledge files, including README, Evidence, Known Unknowns, and dimension-specific documents | Read-only inspection; it does not promote, edit, or validate a claim |
| Source note or annotation | Add source-specific context—owner, purpose, caveat, environment, or an intentional omission—when the source row exposes the Note action | Context accompanies the source; it does not rewrite the underlying file, repository, or database export |
| Tacit knowledge | Add a standalone Markdown note for architecture decisions, operational knowledge, terminology, or history that is absent from system artefacts | Frozen as attributed, human-reported evidence and kept distinct from parsed or observed fact |
The Claude terminal and run activity
Survey, Plan, Extract, and higher-order processing can expose a live Claude terminal beside the lifecycle view. It shows the active agent session, commands, progress, and diagnostic output. The run-activity feed records stage events in a more scannable form.
- Use the terminal to understand what the active stage is doing and to diagnose a pause or failure.
- Expand the terminal when detailed output matters; use the activity feed for stage transitions and completed events.
- Do not treat a quiet terminal or a final line of text as authoritative completion.
- The lifecycle status, persisted artefacts, task ledger, and durable completion markers are the source of truth.
The lifecycle view combines durable job state with a live Claude terminal. Preview actions open the generated files; stage completion still comes from persisted evidence, not terminal appearance. Labels, actions, and layout may vary by release.
Ask is a bounded librarian
Ask is a read-only, capture-scoped interface over claims and curated knowledge documents. It does not modify the capture or silently search beyond the frozen source set.
Durable state and recovery
Progress is judged from durable evidence on disk, not from a terminal merely appearing to finish. A crash, closed laptop, or network drop should not erase completed work. Genesis offers the appropriate resume action from the last durable completion marker.