What is SOCK?
SOCK — System of Connected Knowledge — is the evidence-aware knowledge-capture capability inside Genesis. It captures a bounded snapshot of a codebase, database, document set, or system and makes the resulting knowledge available for review and grounded questions.
SOCK is not an open-ended search index and not a one-shot AI scan. It treats knowledge creation with the discipline of an audit: bounded, versioned, evidence-scored, gap-aware, and recoverable.
The capture library keeps separate, named evidence boundaries for different systems, releases, or scopes. Labels, actions, and layout may vary by release.
The five operating guarantees
| Guarantee | What it means |
|---|---|
| Bounded | Every capture operates against a declared source set. Completion is relative to that boundary, never a claim that the whole enterprise was found. |
| Versioned | A capture is pinned to an exact frozen snapshot: a resolved repository revision, content-hashed files, or a bounded database export. |
| Evidence-scored | Parsed declarations, live observations, AI interpretations, and human reports retain distinct evidence tiers. |
| Gap-aware | Missing, unavailable, unsupported, and unknown evidence stays visible instead of collapsing into false absence. |
| Recoverable | Durable progress lives on disk, so interrupted work resumes from completed checkpoints instead of transient chat history. |
What you can do today
- Create and manage multiple captures for different versions, branches, or scopes.
- Add repositories, folders, files, attributed tacit-knowledge notes, and read-only PostgreSQL, MongoDB, or Oracle connections.
- Preview selected sources, add source-specific context, and preserve attributed tacit knowledge before freezing.
- Freeze, fingerprint, inventory, and attest the source state.
- Run Survey, Plan, Extract, Discover, and Infer against the frozen evidence.
- Create deterministic facts, AI-assisted knowledge narratives, cross-source surfaces, and evidence-linked relationship candidates.
- Preview generated knowledge artefacts, claims, citations, evidence tiers, and known unknowns.
- Ask read-only questions over captured knowledge and inspect cited evidence.
- Resume supported processing after a crash, closed laptop, or network interruption.
The current journey
- 01
1. Supply sources
Declare a bounded evidence set: repositories, approved folders or files, supported databases, and attributed team knowledge.
- 02
2. Freeze
Create a permanent capture-time copy or export. Downstream processing never returns to the changing live source.
- 03
3. Survey
Build the factual source registry, structural inventory, technology signals, and initial coverage boundary.
- 04
4. Plan
Persist a safe execution sequence with per-source work, dependencies, budgets, and read-only attestations.
- 05
5. Extract
Parse declared structures, run per-source comprehension, and retain validated claims with provenance.
- 06
6. Discover
Read across the extracted source units to catalogue higher-order surfaces such as call chains, shared data, integration paths, controls, and change seams that no single source shows.
- 07
7. Infer
Walk each discovered surface to derive deeper node and edge candidates. Keep inferred knowledge explicitly marked and traceable to evidence.
- 08
8. Ask
Query the available claims and knowledge documents. Supported answers cite evidence; unsupported answers remain known unknowns.
Where SOCK fits
SOCK is most valuable when a consequential engineering decision depends on understanding what exists, what may be affected, what evidence supports that view, and what remains unknown.
Change-impact analysis
Assess a proposed change against call chains, contracts, dependencies, data relationships, business rules, reliability controls, and security surfaces—with citations back to captured evidence.
Modernisation assessment
Inventory the as-is estate, locate migration seams and legacy constraints, surface candidate relationships, and expose unknowns before committing scope or sequence.
Incident and problem analysis
Bring configuration, call paths, integrations, data flows, operational components, and reliability evidence together to shorten investigation of unfamiliar failure paths.
Security and compliance review
Review captured controls, interfaces, dependencies, data movement, grants, and compliance evidence while keeping direct observations separate from interpretation.
Architecture and estate discovery
Create an accountable view of components, capabilities, domains, infrastructure, integrations, and interface mappings across an inherited or fragmented system.
Planning and estimation
Ground decomposition and delivery planning in the actual implementation, dependencies, operational constraints, known risks, and visible evidence gaps.
Refactoring and decommissioning
Investigate dependency blast radius, potential dead code, consumers, data relationships, and operational coupling before removing or restructuring a component.
Data-lineage and schema change analysis
Trace captured database objects, contracts, mappings, and candidate data flows to understand where a schema or interface change may propagate.
Engineering onboarding
Give a new engineer a bounded, cited route through responsibilities, journeys, rules, interfaces, operations, and known unknowns without relying only on tribal knowledge.
Audit and technical due diligence
Preserve citable knowledge of an estate at a point in time and make the difference between verified evidence, inference, human report, and missing coverage visible.
Tribal-knowledge risk
Capture attributed human context at a deliberately weaker evidence tier, connect it to available system evidence, and expose ownership or documentation gaps.
Business-to-technology traceability
Relate captured business journeys and rules to domain models, interfaces, data, and implementation surfaces so product intent can be checked against system behaviour.
| Decision or question | Relevant SOCK evidence |
|---|---|
| What could this code, contract, or schema change affect? | Call chains, contract surfaces, interface mappings, data relations, data lineage, and dependency blast radius |
| Where should a modernisation programme begin? | As-is archaeology, legacy-estate map, capability map, migration seams, infrastructure, and operations |
| Why might this failure cross service boundaries? | Reliability map, integration topology, call chains, configuration, operational inventory, and candidate relationships |
| Can this component be retired safely? | Potential dead code, consumers, dependencies, contracts, data relationships, and named evidence gaps |
| Where is sensitive or regulated data exposed? | Security posture, compliance footprint, grants, contract surfaces, data lineage, and captured database structure |
| What should a new engineer understand first? | Business journeys, domain model, capability map, interfaces, operational context, and cited Ask answers |