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:

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.

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

Core definition

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:

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:

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

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

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

Example source types:

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

Adapter output

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:

What did they prove?

Ask:

What object did their mind use to carry the problem?

Then ask:

What did that object become after the adapter translated it?

Process extraction fields

1. Object before

What did the raw problem appear to be?

points
integers
graphs
colors
edges
sets
subsequences
configurations

2. Object after

What did the solver transform it into?

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.

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?

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?

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?

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?

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

Process-to-Mass translation

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

Surface = project_mass_number(MassNumber)

Mapping:

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

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

A2: Probabilistic method adapter

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

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

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

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

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.

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:

This is exactly what the solver thought.

Allowed claim:

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

Minimal working example

For an Erdős-Szekeres convex polygon proof:

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:

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

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.