What is SOCK?
SOCK — System of Connected Knowledge — is the evidence-aware knowledge capability inside MSOCK. It reads a bounded snapshot of a codebase, database, document set, or system and turns it into knowledge you can review, explore, question, and share.
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 practical result is more than an inventory of files. SOCK connects API surfaces, system architecture, execution paths, data movement, business rules, operational controls, dependencies, and unresolved questions into one navigable body of knowledge. That matters when the answer depends on relationships across repositories and technologies—not merely where a keyword appears.
Most engineering tools reveal a slice of the estate. SOCK is intended to let a reviewer move across those slices: from a business journey or interface, through rules and call chains, to data, infrastructure, operations, legacy constraints, and the evidence behind each conclusion. Its 21 analysis dimensions organise that investigation without implying that every source will contain evidence for every dimension.
The harness list makes durable state and the next available action visible. Names, identifiers, descriptions, and workspace totals are masked in this documentation capture.
The five operating guarantees
| Guarantee | What it means |
|---|---|
| Bounded | Every harness works against a declared source list. Completion is relative to that boundary, never a claim that the whole enterprise was found. |
| Versioned | A harness is pinned to an exact locked snapshot: a resolved repository revision, content-hashed files, or a bounded database export. |
| Evidence-scored | Parsed declarations, live observations, AI interpretations, and human reports keep 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. |
The processing stages
- 01
Sources
Declare a bounded evidence set: local repositories and folders, knowledge artifacts, attributed tacit-knowledge notes, and approved read-only PostgreSQL, MongoDB, or Oracle connections. Review the boundary, then lock the source list.
- 02
Scan sources
SOCK copies or exports the evidence, fingerprints it, writes verification records, and builds the factual source registry, structural inventory, technology signals, and coverage boundary. The extraction order — the safe work sequence, with dependencies and budgets — is produced and reviewed in this same stage.
- 03
Extract
Parse declared structures, run per-source comprehension, and keep validated facts with their citations. You approve the extraction order, then run the tasks — one at a time or as a wave.
- 04
Synthesize
Read across every extracted source at once to catalogue discovered items no single source shows, then derive deeper candidate knowledge from them. Inferred knowledge stays explicitly marked.
- 05
Graph
Build the connected estate: identify and classify entities, write capability summaries, map and verify relationships, and record open questions. The result is a graph you can explore visually.
- 06
Review and Ask
Read the ten counts from sources through to billable CKU, and ask bounded questions. Supported answers cite captured evidence; unsupported ones remain Known Unknowns.
- 07
Release
Give the knowledge a version on this machine, and optionally publish that same version to your team.
What the result lets you see
| From a fragmented estate | SOCK makes it reviewable as |
|---|---|
| Routes, schemas, events, and interface code scattered across units | Contract surfaces and interface mappings with citations |
| A request that crosses controllers, services, queues, jobs, and external systems | A cross-source call chain whose members and relationships can be inspected |
| Architecture expressed partly in code, configuration, and deployment artefacts | System and integration views grounded in the captured sources |
| Repeated names or settings whose meaning differs by unit | A visible inconsistency or Known Unknown, rather than a forced conclusion |
| Thousands of concrete technical artefacts | A typed Asset Inventory that can be searched, counted, inspected, and exported |
| Relationships too dense for a flat document | A spatial graph that moves from the whole estate to a plane, object, and evidence-backed connection |
This is the central value of connected knowledge: an engineer can move from an estate-level question to the relevant object and then to its supporting evidence without losing the boundary or confidence level of the answer.
What you can do today
- Create and manage multiple harnesses for different systems, versions, branches, or scopes.
- Add local repositories and folders, knowledge artifacts, 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 locking.
- Lock, fingerprint, inventory, and record verification for the source state.
- Run Scan sources, Extract, and Synthesize against the locked evidence.
- Review the extraction order and approve it before extraction runs.
- Build and explore a connected estate graph of entities and relationships.
- Read the Review counts, including qualified nodes, qualified relationships, and CKU consumption.
- Ask read-only questions over captured knowledge and inspect the cited evidence.
- Open the Asset Inventory report across 12 asset families.
- Release a version locally, publish it to your team, withdraw a local release, and see version history.
- Download a teammate's published harness and read it — including Ask — on your own machine.
- Resume processing after a crash, closed laptop, or network interruption.
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 graph 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 |