Research-Stack/6-Documentation/docs/gcl/CognitiveProcessAdapter.md

# Cognitive Process Adapter

Status: HOLD / adapter doctrine
Authority: workbench synthesis; not formal proof
Related:

- `docs/gcl/ErdosMentalModelMassNumberMap.md`
- `docs/gcl/MassNumberSurfaceTranslation.md`
- `docs/gcl/FrameworkReaderRamp.md`
- `docs/gcl/EquationUnderverseDoctrine.md`

## Purpose

This document defines an adapter for extracting usable process from many mathematical minds.

The premise:

```text
Many minds worked the problem.
The useful artifact is not only the final theorem.
The useful artifact is the process by which each mind made the problem tractable.
```

The adapter converts those processes into Mass Numbers and then surfaces.

```text
mind process -> adapter -> Mass Number -> Surface
```

## Core definition

```text
Cognitive Process Adapter = a translation layer that extracts a solver's modeling process, normalizes it into a Mass Number packet, and projects it into a surface that the stack can compare, reuse, and audit.
```

This is not mind-reading.

It is a disciplined reconstruction from public artifacts:

```text
proofs
papers
lectures
worked examples
failed constructions
counterexamples
notations
diagrams
computational searches
heuristics
historical commentary
```

## Why this exists

Erdos-style domains were not solved by one universal mental method.

They were worked through a cloud of methods:

```text
geometric intuition
order-type compression
probabilistic existence
extremal counting
additive collision control
finite obstruction search
algorithmic enumeration
counterexample farming
notation compression
```

The adapter preserves those methods as reusable process objects.

## Pipeline

```text
Source artifact
  -> Process extraction
  -> Representation shift detection
  -> Invariant detection
  -> Obstruction detection
  -> Proof-engine detection
  -> Underverse shadow detection
  -> Mass Number packet
  -> Surface projection
  -> ACI / Warden validation
```

## Adapter input

```text
ProcessSource = {
  source_id,
  source_type,
  problem_id,
  solver_or_school,
  artifact_kind,
  claim_scope,
  validation_status
}
```

Example source types:

```text
paper
proof sketch
lecture note
computer proof
historical commentary
code repository
counterexample database
worked notebook
```

## Adapter output

```text
ProcessAdapterPacket = {
  problem_id,
  solver_or_school,
  source_artifact,
  object_before,
  object_after,
  representation_shift,
  invariant_focus,
  threshold_pressure,
  obstruction_shape,
  proof_engine,
  search_strategy,
  compression_gain,
  underverse_shadow,
  surface_projection,
  confidence_level,
  evidence_receipt
}
```

## The central adapter question

Do not ask only:

```text
What did they prove?
```

Ask:

```text
What object did their mind use to carry the problem?
```

Then ask:

```text
What did that object become after the adapter translated it?
```

## Process extraction fields

### 1. Object before

What did the raw problem appear to be?

```text
points
integers
graphs
colors
edges
sets
subsequences
configurations
```

### 2. Object after

What did the solver transform it into?

```text
order type
cup-cap sequence
random graph
density threshold
additive collision graph
signature function
finite search tree
energy estimate
container family
```

### 3. Representation shift

The modeling move.

```text
coordinates -> orientations
geometry -> sequence
integer sums -> collision surface
coloring -> obstruction graph
construction -> probability space
proof -> algorithmic certificate
```

### 4. Invariant focus

What stayed meaningful through the translation?

```text
convexity
unique sums
monochromatic clique
edge density
forbidden configuration count
orientation sign
additive energy
```

### 5. Obstruction shape

What was the problem trying to avoid or force?

```text
counterexample
near-counterexample
collision
bad event
forbidden subgraph
non-convex delay configuration
unrealizable signature
search dead branch
```

### 6. Proof engine

What style carried the result?

```text
pigeonhole
induction
probabilistic method
extremal counting
finite geometry
container method
regularity method
energy method
computer enumeration
constructive algorithm
```

### 7. Underverse shadow

What did the method exclude, hide, fail to represent, or leave as residue?

```text
avoiders
failed branches
unrealizable signatures
collision residue
bad-event clusters
unbounded search
lost metric information
near-threshold configurations
```

## Process-to-Mass translation

```text
MassNumber = bind_process(
  representation_shift,
  invariant_focus,
  threshold_pressure,
  obstruction_shape,
  proof_engine,
  underverse_shadow
)
```

The Mass Number does not claim the process is the theorem.

It records how the theorem became visible.

## Mass-to-Surface translation

```text
Surface = project_mass_number(MassNumber)
```

Mapping:

```text
representation_shift -> seam
invariant_focus      -> contour / anchor
threshold_pressure   -> ridge / height field
obstruction_shape    -> hole / wall
proof_engine         -> flow rule
search_strategy      -> path family
underverse_shadow    -> scar field / negative relief
compression_gain     -> gradient shortening
```

## Adapter families

### A1: Geometric intuition adapter

```text
raw object: point configuration
process: see convexity, cups, caps, order, orientation
surface: convexity forcing ridge with non-convex delay holes
```

### A2: Probabilistic method adapter

```text
raw object: hard construction
process: replace construction with random space and bad-event counting
surface: probability-pressure surface with rare-event holes and concentration ridges
```

### A3: Extremal adapter

```text
raw object: large finite structure
process: ask maximum density before a forbidden form appears
surface: density height field with forcing ridge and avoider basin
```

### A4: Additive / Sidon adapter

```text
raw object: integer set
process: translate equal sums into collision topology
surface: additive collision surface with uniqueness basins and repeated-sum scars
```

### A5: Signature / order-type adapter

```text
raw object: coordinates
process: discard metric data and keep orientation signatures
surface: sign-configuration surface with realizability seams and unrealizable scars
```

### A6: Algorithmic obstruction adapter

```text
raw object: possible construction
process: search partial states while maintaining avoidance invariant
surface: search-tree terrain with dead branches, forced contradictions, and certificate ridges
```

## Confidence labels

Adapter outputs must be labeled.

```text
DIRECT:
  source explicitly describes the method

INFERRED:
  method is reconstructed from proof structure

SPECULATIVE:
  method is a useful stack translation but not historically asserted

REJECTED:
  translation does not preserve the source process
```

## Anti-drift rule

Do not claim:

```text
This is exactly what the solver thought.
```

Allowed claim:

```text
This is a faithful adapter for the modeling process visible in the artifact.
```

## Minimal working example

For an Erdős-Szekeres convex polygon proof:

```text
source_artifact: proof / exposition
object_before: finite planar point set
object_after: ordered sequence / cup-cap relation / order type
representation_shift: coordinates -> order / orientation signs
invariant_focus: convex subset
threshold_pressure: point count required to force convex n-gon
obstruction_shape: configurations delaying convexity
proof_engine: geometric Ramsey / pigeonhole / induction / enumeration
underverse_shadow: non-convex delay configurations and near-counterexamples
surface_projection: convexity ridge, avoider holes, order-type seams, cup-cap flow lines
```

## Implementation rule

Every imported process must produce both:

```text
1. a Mass Number packet
2. a Surface projection
```

If it cannot produce a surface, keep it in HOLD state.

If the surface has no invariant, keep it in DRAFT state.

If the surface has no validation path, do not promote it.

## Compact doctrine

```text
The adapter does not collect only what mathematicians proved. It collects how their minds made the problem movable: the representation shift, invariant, obstruction, proof engine, search strategy, and residue. Mass Numbers hold that process. Surfaces render it. ACI and Warden decide whether it is reusable.
```