Assess Form

---
name: assess-form
locale: caveman-ultra
source_locale: en
source_commit: 82c77053
fence_basis_commit: 82c77053
translator: "Julius Brussee homage — caveman"
translation_date: "2026-04-19"
description: >
  Evaluate a system's current structural form, identify transformation pressure,
  and classify transformation readiness. Covers structural inventory, pressure
  mapping, rigidity assessment, change capacity estimation, and readiness
  classification for architectural metamorphosis. Use before any significant
  architectural change to understand the starting point, when a system feels
  stuck without clear reasons, when external pressure from growth or tech debt
  is mounting, or as periodic health checks for long-lived systems.
license: MIT
allowed-tools: Read
metadata:
  author: Philipp Thoss
  version: "1.0"
  domain: morphic
  complexity: basic
  language: natural
  tags: morphic, assessment, architecture, transformation-readiness
---

# Assess Form

Eval current structural form — architecture, rigidity, pressure pts, capacity for change → transformation readiness pre-metamorphosis.

## Use When

- Before significant architectural change → understand starting pt
- System feels "stuck" + reasons unclear
- External pressure (growth, market shift, tech debt) mounting + response uncertain
- Assess proposed transformation feasible given current form
- Periodic health checks long-lived systems (annual form assessment)
- Complementing `adapt-architecture` — assess first, then transform

## In

- **Required**: System (codebase, organization, infrastructure, process)
- **Optional**: Proposed transformation direction (what system need to become?)
- **Optional**: Known pain pts or pressure srcs
- **Optional**: Previous transformation attempts + outcomes
- **Optional**: Time horizon for potential transformation
- **Optional**: Available resources for transformation

## Do

### Step 1: Inventory Current Form

Catalog structural elements no judgment — understand what exists pre-eval.

1. Map structural components:
   - **Modules**: distinct functional units (services, teams, pkgs, depts)
   - **Interfaces**: how modules connect (APIs, protocols, contracts, reporting)
   - **Data flows**: info movement
   - **Dependencies**: what depends on what (direct, transitive, circular)
   - **Load-bearing**: components everything else relies on
2. Doc form's age + history:
   - When each major component introduced?
   - Which changed recently vs static?
   - "Geological layer" structure (old core, newer additions, recent patches)?
3. ID "skeleton" vs "flesh":
   - Skeleton: structural decisions extremely costly to change (lang, DB, deploy model)
   - Flesh: functional decisions easier to change (business logic, UI, config)

```text
Structural Inventory Template:
┌──────────────┬──────────┬────────────┬───────────────────┬──────────┐
│ Component    │ Age      │ Last       │ Dependencies      │ Type     │
│              │          │ Modified   │ (in / out)        │          │
├──────────────┼──────────┼────────────┼───────────────────┼──────────┤
│ Auth service │ 3 years  │ 6 months   │ In: 12 / Out: 3  │ Skeleton │
│ Dashboard UI │ 1 year   │ 2 weeks    │ In: 2 / Out: 5   │ Flesh    │
│ Data pipeline│ 4 years  │ 1 year     │ In: 3 / Out: 8   │ Skeleton │
│ Config store │ 2 years  │ 3 months   │ In: 0 / Out: 15  │ Skeleton │
└──────────────┴──────────┴────────────┴───────────────────┴──────────┘
```

**→** Complete structural inventory: components + ages + mod recency + dep profiles + skeleton/flesh classification. "X-ray" of current form.

**If err:** Inventory incomplete (components unknown/undocumented) → finding — form has opacity = transformation risk. Doc what you can, flag unknowns, plan discovery gaps.

### Step 2: Map Transformation Pressure

Forces pushing change + forces resisting.

1. Catalog external pressures (demanding change):
   - Growth: current form can't handle increasing load
   - Market: competitors/users demand capabilities
   - Technology: underlying becoming obsolete/unsupported
   - Regulatory: compliance reqs current form doesn't meet
   - Integration: must connect w/ systems current form wasn't designed for
2. Catalog internal pressures (demanding change from within):
   - Tech debt: accumulated shortcuts slow dev
   - Knowledge concentration: critical knowledge in too few ppl
   - Morale: team frustration w/ current form
   - Operational burden: maintenance cost consuming dev resources
3. Catalog resistance forces (opposing change):
   - Inertia: existing form works "well enough"
   - Dep lock-in: too many things depend on current form
   - Knowledge loss risk: transformation may destroy institutional knowledge
   - Cost: transformation reqs investment uncertain return
   - Fear: previous attempts failed

**→** Pressure map showing direction + magnitude. Pressure significantly > resistance → transformation overdue. Resistance significantly > pressure → transformation fails w/o first reducing resistance.

**If err:** Balanced picture (neither strong) → system may not need transformation — or analysis surface-level. Dig deeper: interview stakeholders, measure specific pain pts, project 12-18 months. What pressures intensify?

### Step 3: Assess Rigidity

How flexible/rigid is current form — can bend or break?

1. Test interface flexibility:
   - Modules replaceable no cascading changes? (loose coupling = flexible)
   - Interfaces well-defined + stable? (contract clarity = flexible)
   - How many "god modules" exist (all depends)? (concentration = rigid)
2. Test data flexibility:
   - Data migration straightforward? (schema evolution tools, versioning)
   - Data formats standardized or bespoke? (bespoke = rigid)
   - How entangled is business logic w/ data structure? (entangled = rigid)
3. Test process flexibility:
   - Team ship changes quickly? (deploy pipeline health)
   - Test suite comprehensive? (safety net for change)
   - How many "don't touch" components exist? (forbidden zones = rigid)
4. Calc rigidity score:

```text
Rigidity Assessment:
┌──────────────────────┬─────┬──────────┬──────┬──────────────────────┐
│ Dimension            │ Low │ Moderate │ High │ Your Assessment      │
├──────────────────────┼─────┼──────────┼──────┼──────────────────────┤
│ Interface coupling   │ 1   │ 2        │ 3    │ ___                  │
│ God module count     │ 1   │ 2        │ 3    │ ___                  │
│ Data entanglement    │ 1   │ 2        │ 3    │ ___                  │
│ Deployment friction  │ 1   │ 2        │ 3    │ ___                  │
│ Test coverage gaps   │ 1   │ 2        │ 3    │ ___                  │
│ "Don't touch" zones  │ 1   │ 2        │ 3    │ ___                  │
├──────────────────────┼─────┴──────────┴──────┼──────────────────────┤
│ Total (max 18)       │ 6-9: flexible         │ ___                  │
│                      │ 10-13: moderate        │                      │
│                      │ 14-18: rigid           │                      │
└──────────────────────┴───────────────────────┴──────────────────────┘
```

**→** Rigidity score quantifies structural resistance transformation encounters. Flexible (6-9) → incremental. Rigid (14-18) → dissolution before reconstruction (see `dissolve-form`).

**If err:** Inconclusive (moderate score but unclear where real problems) → focus highest-scoring dims. System can be flexible overall but 1 extremely rigid component blocks transformation. Target that specifically.

### Step 4: Estimate Change Capacity

System + team ability to absorb + execute transformation.

1. Available transformation energy:
   - % team capacity allocatable to transformation?
   - Org support (budget, mandate, patience)?
   - Right skills (architecture, migration, testing)?
2. Change absorption rate:
   - How many changes per time unit no destabilize?
   - Recovery time post-significant change?
   - Staging/canary mechanism for incremental?
3. Transformation experience:
   - Team successfully transformed similar before?
   - Tools + practices (feature flags, strangler fig, blue-green)?
   - Risk tolerance?
4. Calc change capacity:
   - High: dedicated team, strong tooling, prior exp, org support
   - Moderate: part-time, some tooling, limited exp
   - Low: no dedicated, no tooling, no exp, resistant org

**→** Change capacity assessment → can execute proposed transformation given resources + skills + org support?

**If err:** Low capacity + high pressure → first transformation isn't system — team capability. Invest tooling, training, org buy-in before architectural transformation.

### Step 5: Classify Readiness

Combine pressure + rigidity + capacity → readiness classification.

1. Plot on matrix:

```text
Transformation Readiness Matrix:
┌─────────────────┬────────────────────────┬────────────────────────┐
│                  │ Low Rigidity           │ High Rigidity          │
├─────────────────┼────────────────────────┼────────────────────────┤
│ High Pressure   │ READY — Transform now  │ PREPARE — Reduce       │
│ + High Capacity │ using adapt-architecture│ rigidity first, then   │
│                 │                        │ use dissolve-form       │
├─────────────────┼────────────────────────┼────────────────────────┤
│ High Pressure   │ INVEST — Build capacity│ CRITICAL — Invest in   │
│ + Low Capacity  │ first, then transform  │ capacity AND reduce    │
│                 │                        │ rigidity before change │
├─────────────────┼────────────────────────┼────────────────────────┤
│ Low Pressure    │ OPTIONAL — Transform   │ DEFER — No urgency,    │
│ + Any Capacity  │ if strategic value is  │ monitor pressure and   │
│                 │ clear, otherwise defer │ reassess quarterly     │
└─────────────────┴────────────────────────┴────────────────────────┘
```

2. Doc classification:
   - Label (READY / PREPARE / INVEST / CRITICAL / OPTIONAL / DEFER)
   - Key findings per dim
   - Recommended next step
   - Risk factors changing classification
3. READY → `adapt-architecture`
4. PREPARE → `dissolve-form` reduce rigidity
5. INVEST → build capacity (training, tooling, org support) + reassess
6. CRITICAL → address capacity + rigidity simultaneously (may need external help)
7. OPTIONAL/DEFER → doc + set reassessment date

**→** Clear justified readiness classification + specific next steps. Enables informed decision about when + how to transform.

**If err:** Ambiguous (moderate pressure + moderate rigidity + moderate capacity) → default PREPARE — reduce rigidity incrementally while monitoring pressure. Builds capability + reduces risk whether or not full transformation eventually needed.

## Check

- [ ] Structural inventory complete: components + ages + deps + types
- [ ] Transformation pressure mapped (external, internal, resistance)
- [ ] Rigidity score calc'd across all dims
- [ ] Change capacity assessed (resources, absorption, exp)
- [ ] Readiness classification determined + justified
- [ ] Next steps documented per classification
- [ ] Reassessment date set (even if currently READY)

## Traps

- **Assess only technical system**: Transformation readiness includes organizational. Technically flexible system + org-rigid team still fails.
- **Optimistic capacity estimation**: Teams consistently overestimate capacity while maintaining normal ops. Use 50% of stated as realistic.
- **Ignore resistance forces**: Pressure mapping only cataloging change forces misses resistance slowing/stopping. Resistance often stronger than appears.
- **Assessment paralysis**: Form assessment hours to days, not weeks. Taking too long → system too complex to assess fully — higher abstraction + drill into problems.
- **Confuse rigidity w/ stability**: Rigid ≠ stable. Stability comes from well-designed flexibility; rigidity = absence of designed flexibility.

## →

- `adapt-architecture` — primary transformation skill; assess-form determines readiness
- `dissolve-form` — PREPARE or CRITICAL → rigidity reduction before transformation
- `repair-damage` — systems needing repair before assessment meaningful
- `shift-camouflage` — surface-level adaptation may resolve pressure no full transformation
- `forage-resources` — resource exploration informs form assessment when "what should we become?"
- `review-software-architecture` — detailed technical architecture eval
- `assess-context` — AI self-application variant; maps structural assessment → reasoning ctx malleability, rigidity mapping, readiness