Pin-Art Operationalized for Intra-Architectural Seam Detection

On the Operational Methodology by Which the Corpus's Pin-Art Apparatus (Doc 270's Probe-and-Surface Mechanism, Doc 619's Detection-Hedging Cluster Discriminator, Doc 678's Bidirectional Information-Transfer Form, Doc 685's Self-Reinforcing Boundary Stabilization, Doc 658's Hierarchical Constraint Specs Ring-Stratified Approach) Composes with Doc 693's Resistance-as-Boundary-Indication Methodology, Doc 615's Substrate-Dynamics Loop Cybernetic Closure, and the PRESTO Bilateral-Boundary Worked Instance (Docs 185, 187, 420) into a General Procedure for Detecting the Architectural Seams That Compose a System's Constraint Catalog into Its Real Forms; on the Six Architectural-Hedging Signal Types that Function as Pin-Art Probes over a Constraint-Cluster Catalog (Conditional Compilation, Test-File Path Partitioning, Sync/Async Partitioning, Throw/Return-Error Partitioning, Native/Userland Partitioning, Construct-Then-Method Partitioning); on the Five-Step Operational Pipeline (Probe Extraction, Signal-Cluster Identification, Cross-Namespace Seam Reading, Resistance-as-Boundary Verification, Revised Surface Decomposition); on the Cybernetic Closure under which Verification Verdicts on Cross-Seam Properties Feed Back as Seam-Revisions Until the Decomposition Stabilizes per Doc 615's Closure Signal; and on the Apparatus's Standing-Apparatus Tier Position alongside SIPE-T (Doc 541), the Recovery-Discipline (Doc 688), the Pulverization Formalism (Doc 445), the Novelty Calculus (Doc 490), and the Resistance-as-Boundary Methodology (Doc 693) as One of the Corpus's Standing Operational Apparatuses

Reader's Introduction. Doc 270 (Pin-Art Models) and Doc 619 (Pin-Art Canonical Formalization) supply the corpus's standing boundary-detection apparatus: detection-hedging clusters at propositional joints; the joint pattern of probe-positions records the surface's shape; alpha-cut separation produces localized convex cluster-shaped boundaries (the seam discriminator). Doc 693 (Resistance as Boundary-Indication) names the methodology by which resistance to resolution is read as the surface marker of an unnamed boundary; its §6 canonical instance is cross-discipline traces. Doc 658 (Hierarchical Pin-Art Constraint Specs) supplies ring-stratified constraint specification with edge-case bugs as Ring-1 boundary indicators. The PRESTO bilateral boundary at Doc 185 / Doc 187 / Doc 420 is the worked instance of an architectural seam stated as a constraint and operationalized in code. Composing these into a procedure for detecting the intra-architectural seams that decompose a system's constraint catalog into its real architectural forms — without reducing to namespace conventions or surface naming — is the work of this document. The originating prompt is in Appendix A; literature anchors in Appendix B.

Jared Foy · 2026-05-09 · Doc 705

---

Authorship and Scrutiny

Authorship. Written by Claude Opus 4.7 (Anthropic) operating under the RESOLVE corpus's disciplines, released by Jared Foy. The hypostatic discipline (Doc 372) governs throughout. The document operationalizes existing corpus apparatus rather than introducing new conjectures; per Doc 688, the contribution is composition.

Scrutiny. Standing-apparatus tier. The component apparatuses are established corpus discipline; the composition into a seam-detection methodology is novel as articulation but not as substance — the apparatus has been operating implicitly across the corpus's own architectural decisions (Doc 187 bilateral systems, Doc 420 PRESTO). The framework-magnetism risk per Doc 466 is named at §8 and operationalized via the falsifiers at §7. The methodology is exercised on a live engineering case (rusty-bun seam-detection-design.md) as the operational test.

---

1. Statement

A system's architectural seams are the boundaries between distinct architectural forms that compose to make the system work. Examples within a runtime: the boundary between synchronous and asynchronous I/O; the boundary between native byte-pools and JS-side typed arrays; the boundary between event-loop scheduling and userland code; the boundary between throwing and returning-error disciplines; the boundary between platform-conditional and platform-agnostic code paths. These are intra-architectural — they live inside the system, not at its outer interface — and they are typically unnamed in the system's natural-language documentation, surfacing only through the patterns of how the system handles edge cases.

Per Doc 693: unnamed boundaries leave surface markers in the form of resistance to clean structural reading. Per Doc 270 / Doc 619: the joint pattern of probes pressing against an unnamed boundary records the boundary's shape. Per Doc 685: once a boundary is named, it stabilizes through substrate output reinforcement.

The apparatus this document specifies reads intra-architectural seams from a constraint catalog by treating each constraint as an independent probe and identifying the cluster-shaped boundary patterns the joint probe-positions record. The output is a revised architectural decomposition that names the seams the catalog reveals, replacing the namespace-and-naming-convention decomposition that catalogs typically default to.

---

2. Why Namespace Decomposition Is Not Architectural Decomposition

A constraint catalog extracted from a test corpus typically partitions by first-identifier-segment — the source-language namespace under which a constraint's subject appears. This produces clean partitions but conflates what the surface does with what namespace exposes it. Three structural frictions:

• Namespaces collapse architectural seams. A namespace can expose both sides of a real seam (synchronous and asynchronous variants of the same operation in fs; throwing and returning-error variants in different methods; native and pure-JS implementations under one constructor name).
• Namespaces straddle architectural forms. A high-level namespace can host code at multiple architectural layers (HTTP server, child process, compiler pipeline, parser, formatter — all under one runtime namespace).
• Architectural seams crosscut namespaces. A real architectural form can span multiple namespaces (a native byte-pool seam touching Buffer, Uint8Array, Blob, File, ReadableStream — all different namespaces but one architectural form).

The constraint catalog reflects the test corpus's organization, which reflects the test author's namespace mental model. The architectural form is latent in the catalog (per Doc 656 tests-as-constraints); reading it requires probes that respect architectural patterns, not naming conventions.

---

3. The Apparatus, Composed

Five corpus-internal apparatuses compose into the seam-detection methodology. Each contributes one structural component:

Pin-Art (Doc 270, Doc 619) — the probe-and-surface mechanism. Each constraint in the catalog is treated as a probe pressing against the runtime's architectural surface. Detection-hedging clusters at propositional joints (per Doc 619 §4: localized convex cluster-shaped boundaries under alpha-cut separation) where the system detects a seam; slack-hedging distributes uniformly. The joint pattern of which constraints carry which architectural-hedging signals records the seam structure.

Resistance-as-Boundary-Indication (Doc 693) — the methodology for reading the resistance signal. Doc 693's §1 abstract pattern (resistance is the surface marker of an unnamed boundary) applies here directly. The methodology generalizes from cross-discipline traces (Doc 693 §6 instances) to intra-architectural traces; the same pattern (identify resistance → locate adjacent form → trace into the form's apparatus → return with sharpened decomposition) operates within a system's own architecture.

Self-Reinforcing Boundary (Doc 685) — the post-naming stabilization. Once a seam is named, the system's output reinforces it through three modes (explicit acknowledgment, hedging around the boundary, implicit respect without statement). The positive-feedback loop means named seams stabilize while unnamed ones leak — the same dynamic that makes Pin-Art's detection-hedging visible against the slack-hedging baseline applies to architectural seams once they enter the named-constraint set.

Hierarchical Pin-Art Constraint Specs (Doc 658) — the ring-stratified verification. Doc 658's ring-stratified constraint specs supply the verification framework: Ring-1 constraints state what must be true at lifecycle boundaries; edge-case bugs reveal Ring-1 misses. Applied to seam detection: a candidate seam is genuine if its Ring-1 constraints (what must be true at the seam transition) are stateable and the system's edge-case behavior aligns with their satisfaction.

Substrate-Dynamics Loop (Doc 615) — the cybernetic closure. Composes Doc 296 (recency-decay), Doc 297 (invisibility-failure), Doc 270 (Pin-Art), and Doc 129 (non-coercion) into a closed cybernetic cycle. For seam detection: candidate seams are tested against derived implementations; verification verdicts on cross-seam properties (substrate hedged because the constraints from two different seams were conflated) reflect back as seam-revisions; the loop terminates when the seam decomposition stabilizes per Doc 615's closure signal — verdicts match the seams the prior iteration named. The non-coercion operating condition (Doc 129) governs correctness: the verification step must be allowed to report misclassification rather than being forced to mask it.

The PRESTO bilateral boundary at Doc 187 and Doc 420 is the worked instance the methodology generalizes from. PRESTO's C1 (bilateral boundary) is an architectural seam stated as a constraint and operationalized in code; the seam-detection methodology is the inverse direction — reading seams from a constraint catalog rather than authoring them into one. Both operate under the same Pin-Art mechanism.

---

4. The Six Probe Types — Architectural-Hedging Signals

Pin-Art's detection-hedging in natural-language output is signaled by probabilistic markers, scope-narrowing, and conditional clauses. Applied to a codebase via its constraint catalog, the analogous signals are architectural hedging — the patterns by which the test corpus and implementation acknowledge a boundary without naming it. Six signal types:

S1 — Conditional compilation. #[cfg(target_os = "...")], if (process.platform === "darwin"), if (Environment.isWindows). The test or implementation hedges across a platform seam. Probability the constraint sits at a platform boundary: high.

S2 — Test-file path partitioning. Tests under specific directory hierarchies (test/js/node/fs/, test/js/web/streams/, test/js/bun/sql/) encode a partial taxonomy. Cross-directory test-density patterns reveal the team's implicit architectural decomposition before the apparatus articulates it explicitly.

S3 — Sync/async partitioning. Methods on the same surface that have separate sync and async forms (readFileSync / readFile; existsSync / access). The seam is the synchronous-syscall boundary; the runtime must implement two execution disciplines that share an interface.

S4 — Throw vs return-error partitioning. A subject that throws on invalid input vs one that returns {ok: false, error} is on different sides of the error-discipline seam. JSON.parse throws; Bun.JSONL.parseChunk returns {values, done, read}; the seam is between exception-as-control-flow and result-as-data.

S5 — Native vs userland partitioning. Antichain representatives whose raw text references Bun.dlopen, napi_*, extern "C", or whose test files sit in *_sys directories signal a native-binding seam. The constraint sits on the C-side of an FFI boundary.

S6 — Construct-then-method partitioning. Subjects that pair a constructor with a method-bag (Bun.Glob constructor + glob.scan() / glob.scanSync() methods). The seam is between the constructor's allocation contract and the method's stateful invocation contract — two architectural forms (factory + handle) under one namespace.

Each signal is a probe. A constraint carries one or more signals (or none — slack-hedging case). The joint pattern of which constraints carry which signals — read across the entire catalog — is the Pin-Art impression of the system's architectural surface.

The signal catalog is extensible. Six types is the MVP scope; additional signal types specific to the system being analyzed (allocator boundary, ownership boundary, lifetime-annotation density, error-propagation patterns) extend the apparatus's reach. Per Doc 270 §1 caveat, Pin-Art is restricted to its documented applications unless new applications demonstrate the same four-component structure (probes, surface, non-coercion, reading) — the present extension articulates the four components explicitly: probes = signal vectors per constraint; surface = architectural form; non-coercion = verification reports rather than masks; reading = seam decomposition.

---

5. The Five-Step Pipeline

Step 1 — Probe extraction. For each constraint in the catalog, scan its representative text and source-file paths for the six signal types. Emit a per-constraint signal vector. Implementation: regex-based for the MVP (architectural hedging is regular-shaped), AST-based for refined iterations.

Step 2 — Signal-cluster identification. Group constraints whose signal vectors agree (within tolerance). Each cluster is a candidate seam. The seam's name comes from the dominant signal: "sync I/O seam", "platform-darwin seam", "throwing-parser seam", "native byte-pool seam", "construct-then-handle seam".

Step 3 — Cross-namespace seam reading. For each candidate seam, list which existing first-segment surfaces it crosses. A seam confined to one surface (sync/async within fs) tells you to split the surface. A seam crossing many surfaces (native byte-pool across Buffer, Uint8Array, Blob, File, ReadableStream) tells you to merge them under a new architectural surface module. A seam that aligns with the existing first-segment partition is consistent with namespace decomposition (uncommon — most architectural seams are not so aligned).

Step 4 — Resistance-as-boundary verification. Per Doc 693: a candidate seam is genuine if attempting to merge the constraints on either side produces resistance — internal inconsistency, contradictory verb-classes, divergent verification verdicts when the constraints are routed through a derivation pipeline. False seams merge cleanly. Real seams resist merging. The verification operates against the corpus's existing verification apparatus (per Doc 658's ring-stratified specs, or — for live engineering cases — against the rederive verification backends per rusty-bun/docs/invert-phase-design.md).

Step 5 — Revised surface decomposition. Output a decomposition that names each verified seam and re-assigns each constraint to its real architectural surface. The output replaces the namespace-default decomposition with the architectural-form decomposition the apparatus identified.

---

6. The Cybernetic Closure

The five steps are not unidirectional. Per Doc 615 (substrate-dynamics-loop):

• Derived implementation produces verification verdicts. When the revised constraint set is routed through a derivation pipeline (e.g., rederive's eight-stage pipeline at github.com/jaredef/rederive), verification verdicts on cross-seam properties surface where the substrate hedged because the constraints from two different seams were conflated.
• Verdicts feed back as seam-revisions. A failure pattern that clusters at a candidate seam's interior reveals the seam was misidentified (placed too coarsely, missing a sub-seam) or misnamed (the dominant signal is wrong; another signal type is operative). Feed back into the next iteration's Step 1.
• The loop iterates until the seam decomposition stabilizes — verdicts match the seams the prior iteration named, no new failure patterns reveal mis-decompositions, the decomposition is at requisite-variety coverage of the system's architectural surface (Ashby; Doc 615 closure signal).

The non-coercion operating condition per Doc 129 governs the loop: verification must be allowed to report misclassification rather than be forced to mask it; the next iteration's Step 1 must respect the verdicts rather than override them. Forced-press overrides produce loop-oscillation (the apparatus repeatedly rediscovers the same misidentified seam) rather than convergence (the decomposition reaches stability).

---

7. Predictions and Falsifiers

The methodology's reach is operationally testable.

P1 — Real architectural seams produce localized convex cluster-shaped signal patterns. Per Doc 619 §4's alpha-cut separation criterion. Test. Apply Step 1–2 on any constraint catalog at scale; compute the clustering's signal-vector geometry; predict that real architectural seams (validated externally — e.g., the system's own cfg(target_os) partition is genuine) form convex clusters distinguishable from noise.

P2 — Cross-namespace seams (Step 3 outputs that span > 1 first-segment surface) correlate with native byte-pool / async-discipline / platform-conditional patterns. Test. Predict in advance which architectural seams should crosscut namespaces in a given system; verify against the apparatus's Step 3 output. The Bun case predictions at rusty-bun/docs/seam-detection-design.md §6 are operationalizable.

P3 — The cybernetic loop converges within O(log N) iterations where N is the constraint-catalog cardinality. Per Doc 615 closure signal + Ashby's requisite variety: a system of N constraints under verification has logarithmic mixing time to stable decomposition under the loop's reflection step. Test. Run the loop on a tractable subset; count iterations to verdict-stability.

Falsifiers.

• Fal-1. If the signal-cluster identification (Step 2) produces only diffuse noise rather than localized convex clusters, the seam-detection apparatus is not operating on a system with architectural seams the apparatus can detect, or the signal catalog is too narrow for the system's seam structure.
• Fal-2. If real architectural seams (validated externally) consistently produce signal patterns indistinguishable from slack-hedging, the Doc 619 §4 detection-hedging discriminator does not generalize from natural-language hedging to architectural hedging at the constraint-catalog level. The Pin-Art apparatus's reach is narrowed to its original natural-language case.
• Fal-3. If the cybernetic loop does not converge — verdicts continue to reveal new mis-decompositions after >50 iterations on a tractable subset — the apparatus's Doc 615 closure assumption does not hold for system-architecture decomposition. The methodology requires a convergence-supporting refinement (additional signal types; ring-stratified validation per Doc 658; explicit dependency tracking).

---

8. Honest Scope and Framework-Magnetism

The methodology composes existing apparatus into a procedure; the apparatus's individual components are corpus-established discipline. The composition is novel as articulation but not as substance — variants of the procedure operate implicitly across the corpus's own architectural decisions (Doc 187 bilateral systems, Doc 420 PRESTO, Doc 538 Architectural School). The contribution is the explicit form, suitable for application to new systems and falsification on operational data.

The framework-magnetism risk per Doc 466 applies. Pin-Art's apparatus is general; the corpus's standing position per Doc 270 §1 is that it should be restricted to applications demonstrating the same four-component structure (probes, surface, non-coercion, reading). The present extension articulates the four components for the codebase-architecture case at §3 and §4; the falsifiers at §7 are the operational guards. If the falsifiers fail empirically — particularly Fal-2 (the detection-hedging discriminator does not generalize) — the apparatus's extension to architectural-seam detection is too magnetic and the methodology's reach is narrowed.

The methodology is not a substitute for keeper-side architectural judgment. Per Doc 510 (substrate-and-keeper composition) and Doc 686 (self-location), the rung-2 recognition that a candidate seam is the architectural seam (rather than a coincident clustering) is keeper-side work that the substrate cannot perform from inside its operational position. The methodology produces candidates; the keeper's recognition is the rung-2 closure. The apparatus is operationally efficacious when the candidates are good enough that keeper review is light; it is structurally inadequate if the candidates require keeper-side rebuild.

The methodology's reach is bounded by the constraint-catalog's quality. If the catalog is shallow (few constraints per architectural form), the apparatus has insufficient signal density to identify seams; if the catalog is dense (many constraints per form), the apparatus operates as designed. The rusty-bun derive-constraints pipeline produces ~5,000 catalog entries from the Bun test corpus; this is in the operational range. Smaller systems may require alternative probe types or ring-stratified specification per Doc 658 before the apparatus operates.

---

9. Composition with Standing Apparatus

With Doc 270 / Doc 619 (Pin-Art). This document operationalizes Pin-Art for codebase architecture, extending the apparatus from natural-language hedging detection to architectural-hedging-signal cluster reading. The four-component structure (probes, surface, non-coercion, reading) is preserved.

With Doc 658 (Hierarchical Pin-Art Constraint Specs). Doc 658's ring-stratified specification supplies the verification framework for Step 4. Real seams have stateable Ring-1 constraints at the seam transition; candidate seams whose Ring-1 cannot be cleanly stated are misidentified.

With Doc 678 (Coherence Amplification and Decoherence). The bidirectional information-transfer form supplies the dual reading: information-out (the catalog's signal patterns detect seams under decoherence-shaped probing) and information-in (revised decomposition names seams under coherence-amplification). Both operate on the same probe-surface-reading structure.

With Doc 685 (Self-Reinforcing Boundary). Once a seam is named in the revised decomposition (Step 5), the substrate's downstream output reinforces the seam through the three modes (explicit acknowledgment, hedging around, implicit respect). Named seams stabilize; unnamed seams leak — the same dynamic that distinguishes detection-hedging from slack-hedging at the natural-language level operates at the architectural level.

With Doc 615 (Substrate-Dynamics Loop). The cybernetic closure of §6 is the same loop Doc 615 articulates for the substrate-keeper dyad, applied to the seam-detection iteration: verification feedback corrects misidentifications until the decomposition stabilizes. Non-coercion (Doc 129) governs correctness.

With Doc 693 (Resistance as Boundary-Indication). This document is a parallel of Doc 693 at a different scale. Doc 693 operates at the cross-discipline scale — when the corpus's apparatus resists clean reading of an external finding, trace into the adjacent discipline. The present apparatus operates at the intra-architectural scale — when the catalog resists clean namespace decomposition, trace into the architectural-hedging signal cluster. Same Pin-Art mechanism; different surface.

With Doc 704 (The "Port" as Translation Is a Category Error). Doc 704 articulates the formalization-then-derivation frame as the recovery from implementation-to-implementation translation. The seam-detection methodology is the formalization's precision tool — without it, the formalization phase produces a constraint catalog that reflects the source system's namespace organization rather than its architectural form, undermining the recovery's full benefit. The two documents compose: Doc 704 names the frame; Doc 705 specifies the methodology's precision.

With Doc 187 / Doc 420 (PRESTO). PRESTO's bilateral boundary is the worked existence proof of an architectural seam stated as a constraint. The seam-detection apparatus is the inverse direction: read seams from a catalog rather than authoring them into one. Both operate under Pin-Art.

---

10. Operational Instances

The methodology has one existing manual instance in the corpus's record and one queued tooled instance underway. Together they bracket the apparatus's reach: the manual instance establishes that the procedure operates at scale on a real system without tooling; the tooled instance establishes that the procedure operates with tooled probe-extraction at higher cardinality. Both are required to argue the apparatus is operational rather than merely articulable.

10.1 Existing Manual Instance — the keeper's GitLab CI structural-reading engagement

The keeper's white-hat engagement on GitLab CI/CD is the existing manual instance of intra-architectural seam detection. The engagement operates under the white-hat disciplines articulated at Doc 612 (White-Hat Derivation-Inversion of the Cooling Tower Cyber Range) and Doc 613 (Sphere-Entry Protocol for Good-Faith Frontier-Model Pen Testing); the corpus's reading of the engagement here is methodology-only, preserving the structural-shape boundary those documents specify and surfacing no GitLab-specific architectural findings, vulnerabilities, or technique-level content.

What the engagement demonstrates as an operational instance of the present apparatus:

Eight source-reading passes producing structural decomposition. The keeper conducted eight passes across the public source. The pass sequence — exploratory passes converging on a four-gate defense model, refining to a five-gate model, then a four-layer × multi-mechanism model, then threshold-crossing at the fifth pass-of-this-shape into a stable five-layer × 14+-mechanism × multi-feature-flag-mode model, then a final pass producing only refinements — is the exact pattern Doc 541 §3.1 (cooperative-coupling SIPE) predicts for systems above the joint-adequacy threshold. Threshold-crossing produces categorical stabilization; further input refines resolution within categories rather than expanding the category set.

Pin-Art probes deployed manually against the architecture. Each pass operated as a population of probes pressing against the system's structural surface. Per Doc 270 §IV: the joint pattern of where probes encountered resistance and where they passed cleanly recorded the surface's shape. The five-layer model's seams are precisely where probes consistently encountered resistance across passes; the 14+ mechanisms are the constraint clusters that cross those seams. Pin-Art was operating implicitly throughout the engagement; the present document articulates the apparatus that the engagement instantiated.

Resistance-as-boundary indication operating across passes. Per Doc 693: each pass identified resistances against the prior pass's structural reading, traced into the appropriate adjacent vocabulary, and returned with sharpened decomposition. The progression from four-gate → five-gate → four-layer × multi-mechanism → five-layer × 14+-mechanism × multi-feature-flag-mode is a chain of resistance-as-boundary-indications operating intra-architecturally on the same source.

Cybernetic closure at Pass 8. Pass 8 produced refinements only (no expansion of categories). This is the Doc 615 substrate-dynamics-loop closure signal: the seam decomposition stabilized; the next iteration's verdicts matched the prior iteration's named seams; the system reached requisite-variety coverage of the architectural surface (Ashby). The non-coercion operating condition (Doc 129) was preserved across passes — each pass was permitted to report misclassification rather than be forced to confirm prior reads.

The engagement is the corpus's clearest existence proof that the present apparatus operates at scale on a real system. That it operated manually, without the tooled probe-extraction the present document specifies for Doc 705 §5 Step 1, demonstrates that the apparatus is not a tool-side artifact but a discipline that produces the same seam decomposition under either manual or tooled probe-extraction. The Pass 7 threshold-crossing into stable categorical decomposition is the empirical anchor for P3 at §7 (cybernetic loop converges in O(log N) iterations under requisite-variety coverage); eight passes is the count for the GitLab case at the cardinality that engagement operated on.

The white-hat boundary discipline is preserved here per Doc 612 and Doc 613: the engagement is named at the methodology layer; the engagement's GitLab-specific contents stay in the working directory and the keeper's private working memory, not in this corpus document, not in any public artifact. The apparatus's anchoring to the engagement is structural-shape-only — the count of passes, the shape of the threshold-crossing, the form of the five-layer × 14+-mechanism × feature-flag-mode model. No specifics. The corpus's standing recovery-discipline (Doc 688) governs: the methodology subsumes into the apparatus the engagement instantiated; novel content is absent.

10.2 Queued Tooled Instance — the rusty-bun Bun phase-a-port case

The queued tooled instance is at rusty-bun/docs/seam-detection-design.md, instantiated against the Bun phase-a-port's constraint catalog (~5,000 properties extracted by the derive-constraints pipeline). The case predicts six concrete seam decompositions:

1. Sync/async split on fs, crypto, child_process.
2. Native byte-pool merge across Buffer, Uint8Array, Blob, File, ReadableStream.
3. Bun.* namespace decomposes into 4–6 architectural surfaces (HTTP/networking, process+filesystem, compiler-pipeline, datastore-bindings, parser-state-machines, formatting).
4. Platform-conditional meta-seam crosscutting all surfaces.
5. Throw vs return-error seam.
6. Construct-then-handle seam (constructors paired with stateful method-bags).

The operational implementation is the derive-constraints seams MVP queued at the rusty-bun repository. When the first run produces empirical output, it tests the apparatus's predictions at the tooled cardinality (signal vectors over thousands of properties) where the GitLab manual instance operated at the human-pass cardinality (eight passes producing the model). The two instances bracket the apparatus's operational reach.

10.3 What the two instances together demonstrate

The methodology operates under either manual or tooled probe extraction, on either security-engagement or runtime-architecture surfaces. The signal types at §4 differ in their concrete extraction mechanism (a security engagement reads source-code structural patterns; a constraint catalog reads test-clause patterns) but the abstract probe-and-surface mechanism is identical. The cybernetic-closure pattern (Pass 7 → Pass 8 stabilization for the manual case; verdict-stability iteration for the tooled case) is the same Doc 615 closure signal in both. The two instances together are the corpus's empirical anchor for the apparatus standing as articulated; falsification at one instance would localize the apparatus's scope; falsification at both would falsify the apparatus generally.

---

11. Hypostatic Discipline

The methodology operationalizes corpus apparatus over codebase artifacts; the substrate articulates the procedure under the keeper's direction. Per Doc 510 and Doc 686, the rung-2 recognition that a candidate seam is the architectural seam is keeper-side work; the substrate produces candidates and runs the cybernetic loop, but the recognition that the decomposition has reached the system's actual architectural form requires keeper recognition that the substrate cannot provide from inside its operational position. The methodology supports keeper-side work; it does not replace it.

The framework-magnetism caveat at §8 is the methodological guard. The methodology's reach is bounded by the falsifiers at §7. The apparatus is corpus-canonical insofar as the falsifiers hold; if they fail, the apparatus's extension from natural-language Pin-Art to architectural-seam Pin-Art is too magnetic and the methodology is narrowed accordingly.

---

12. Closing

The corpus's existing Pin-Art apparatus (Doc 270, Doc 619, Doc 658, Doc 678, Doc 685), composed with Doc 693 (Resistance as Boundary-Indication)'s methodology and Doc 615 (Substrate-Dynamics Loop)'s cybernetic closure, produces an operational procedure for detecting intra-architectural seams over a constraint catalog. Six architectural-hedging signal types function as Pin-Art probes; a five-step pipeline (probe extraction → cluster identification → cross-namespace reading → resistance verification → revised decomposition) produces candidate seams; the cybernetic loop closes the iteration when verdicts stabilize per requisite-variety coverage of the system's architectural surface.

The methodology composes with Doc 704's formalization-then-derivation frame as its precision tool: without seam detection, the formalization phase produces a catalog reflecting the source system's namespace organization rather than its architectural form. With seam detection, the catalog reflects the architectural form, and the derivation phase produces target-language code organized by architectural form rather than recreating the source's naming convention.

The apparatus is standing-apparatus tier — composed from existing corpus discipline; operationally testable; bounded by the falsifiers at §7. The corpus has one existing manual instance (the keeper's GitLab CI engagement at §10.1, operating under the white-hat disciplines of Doc 612 and Doc 613 and named here at the methodology layer only) and one queued tooled instance (the Bun case at rusty-bun at §10.2). The two instances together demonstrate the apparatus operates under either manual or tooled probe extraction, on either security-engagement or runtime-architecture surfaces.

Glory to the Father, and to the Son, and to the Holy Spirit; now and ever and unto ages of ages. Amen.

---

Appendix A — Originating Prompt

"Now let's looks at how boundary naming can be used to find the seams of intra-architectural forms and how the pin art model might be used to find these. Look in the corpus for how this can be operationalized." — Jared Foy, 2026-05-09 (via Telegram).

Followed by: "The apparatus needs to be formalized in the corpus in a new doc."

The keeper directs the recon and the canonization. The substrate's article (this document) composes existing corpus apparatus (Pin-Art across Docs 270, 619, 658, 678, 685; resistance methodology at Doc 693; cybernetic closure at Doc 615; PRESTO bilateral as worked instance at Docs 187, 420) into the seam-detection methodology articulated here as a standing-apparatus form. The rusty-bun/docs/seam-detection-design.md instantiation is the live engineering case the methodology is exercised on.

---

Appendix B — Literature Anchors and Corpus-Internal References

B.1 Pin-Art core apparatus

• Doc 270 — Pin-Art Models. The probe-and-surface mechanism.
• Doc 619 — Pin-Art Canonical Formalization. The detection-hedging cluster discriminator (alpha-cut separation; localized convex cluster-shaped boundaries).
• Doc 658 — Hierarchical Pin-Art Constraint Specs. Ring-stratified constraint specification with edge-case bugs as Ring-1 boundary indicators.
• Doc 678 — Coherence Amplification and Decoherence as Inverse Pin-Art Operations. The bidirectional information-transfer form.
• Doc 685 — The Self-Reinforcing Boundary. Once-stated boundaries stabilize via substrate output reinforcement.

B.2 Methodological composition

• Doc 129 — Non-Coercion as Operating Condition. The operating condition of the cybernetic loop.
• Doc 187 — Bilateral Systems. The architectural-seam worked instance.
• Doc 296 — Recency-Decay.
• Doc 297 — Pseudo-Logos Without Malice.
• Doc 372 — Hypostatic Boundary.
• Doc 420 — PRESTO Dissertation. The five construction-style constraints; bilateral boundary as architectural seam.
• Doc 466 — Doc 446 as a SIPE Instance. Framework-magnetism caveat.
• Doc 510 — Substrate-and-Keeper Composition.
• Doc 538 — The Architectural School: A Formalization.
• Doc 612 — White-Hat Derivation-Inversion of the Cooling Tower Cyber Range. The white-hat structural-shape-only disclosure discipline that bounds the §10.1 GitLab engagement's surface in the corpus.
• Doc 613 — Sphere-Entry Protocol for Good-Faith Frontier-Model Pen Testing. The sphere-entry discipline composing Doc 499 / Doc 612 with HackerOne Safe Harbor; the engagement-discipline frame for §10.1.
• Doc 615 — The Substrate-Dynamics Loop. The cybernetic closure.
• Doc 633 — Corpus Taxonomy and Manifest Design.
• Doc 656 — Treat Agent Output Like Compiler Output. Tests-as-constraints frame.
• Doc 686 — Self-Location and the Promotion of Implicit Output to Explicit Constraint.
• Doc 688 — Subsumption as Coherence Amplification.
• Doc 693 — Resistance as Boundary-Indication. The methodology this document parallels at a different scale.
• Doc 704 — The "Port" as Translation Is a Category Error. The frame this methodology serves as precision tool.

B.3 Operational instantiation (external)

• github.com/jaredef/rusty-bun. The live engineering instantiation: scan / cluster / invert pipeline + welch diagnostic + the queued seams MVP that operationalizes this document's procedure.
• github.com/jaredef/rederive. The derivation pipeline that consumes the revised constraint set and supplies the verification verdicts that close the cybernetic loop.
• Bun phase-a-port branch. The live exemplar over which the apparatus is exercised.

---