apexSolarKiss/urban-observatory is the newer pressure surface that exposed method-layer material asset-pipeline-ASK had not pressured. The project is in early bootstrap / prototype-planning phase, and its pressure has been concentrated at inception and instantiation: source-of-intent recovery, validation loops, bootstrap grounding-note lifecycle, and the external-handoff classification observation.

The role is structural, not biographical. The project is the worked example; the method is the durable element.

The following method elements emerged through urban-observatory work:

• Source-of-intent recovery as architecture — the load-bearing sequence recovered intent → validated constraint → repo. Project inception from messy AI-mediated exploration requires reconciliation of overlapping conversation captures before any synthesis can begin.
• Validation loop discipline — the structural pattern that keeps the model from authoring the source of intent it is supposed to serve. AI does not produce another polished frame; the operator validates against durable purpose.
• Bootstrap / post-bootstrap grounding-note freshness — pre-repo grounding notes carry repo-shape thinking, planned file inventory, "future repo" framing. Once the repo exists and owns project truth, that material becomes fast-aging.
• Architecture-uncertain instantiation pressure — validated that the architecture-uncertain overlay generalizes beyond asset-pipeline-ASK to a second pressure surface.
• Cross-surface critique as method instrument — the protocol repo was reviewed not only against its own grounding note but in the context of its downstream repos and their grounding notes. That broader synthesis caught a failure mode that downstream-local critique could not.
• External-handoff classification (observation-level) — urban-observatory's grounding note v12 added a project-specific domain-authority handoff classification guardrail. ASK is the project's architect/operator; its domain authority / strategic vision is Teresa (TMK). The method-relevant issue is how domain-authority input is classified before it reshapes current repo work. The five-category classification (valid source-of-intent / current-stage refinement / future roadmap / advisor scratch / premature implementation architecture) is project-specific; the generalized observation that external source-of-intent loops may benefit from stage-aware classification is preserved at observation-level pending further evidence (typically a second project showing the same pressure, or a strong structural argument).

control-surface absorbed the patterns that generalize beyond the urban-observatory domain:

• Post-Bootstrap Trim Pass in templates/grounding-note.template.md — the lifecycle gate that forces a pre-repo grounding note to shed fast-aging setup material once the repo begins owning project truth
• Pointers from the project-instantiation prompt, advisor template, and workflow doc to the new gate
• Architecture-uncertain rules overlay generalizability validated (the overlay was already in control-surface; urban-observatory pressure confirmed it earns its place beyond asset-pipeline-ASK)
• control-surface/examples/urban-observatory/notes.md workflow-asset summary

Per the absorption discipline, control-surface explicitly declined to absorb the external-handoff classification rule. The project-specific guardrail stays in urban-observatory's grounding note; the generalized observation routes here.

docs/method.md references urban-observatory contextually in source-of-intent and adversarial-iteration sections. docs/source-of-intent.md carries the recovered-intent / validation-loop pattern as method doctrine and the external-handoff classification as an observation-level subsection — explicitly labeled, with the candidate generalization stated but not promoted to rule.

Domain-specific content lives in apexSolarKiss/urban-observatory, not here:

• urban-policy, planning, and public-data domain details
• the project's source packs, conversation captures, and intent-recovery records
• the project-specific domain-authority handoff classification guardrail itself (lives in urban-observatory's grounding note v12)
• protected payloads (project-specific source-of-intent loops, project positioning, planning-domain vocabulary)

Method-ASK carries only what generalizes beyond the urban-observatory domain. The domain-authority handoff instance is preserved here at observation-level only; if a second project surfaces the same external-source-of-intent-loop pressure, the pattern may earn rule-level treatment in a future docs/external-handoff-classification.md.