Formalising the Pattern Publication System

This week’s focus

This week focused on evolving and stabilising the Architecture Pattern system so that extraction, transformation, and publication operate as a governed pipeline rather than ad-hoc documentation.

Related experiment: Agentic Architecture Pattern System

What actually happened

• Identified incompatibility between the pattern extractor JSON schema and the Pattern Markdown template.
• Extended the extractor schema to include an agentic_profile block capturing system shape, orchestration mode, interaction style, tool protocol usage, optimisation targets, and simplicity vs autonomy.
• Introduced explicit use of unknown for non-evidenced agentic dimensions and required evidence when marking MCP or tool usage as present.
• Clarified that agentic_profile is descriptive metadata, not a gating criterion for pattern validity.
• Updated the transformer prompt to map agentic_profile deterministically and avoid implicit multi-agent assumptions.
• Updated the RUNBOOK with Pattern Origins (execution-derived v1), Pattern Lifecycle states, and a formal Pattern Publication Flow (Extractor → Transformer → Review → Publish → Back-reference).
• Added a Definition of Done for pattern publication and reinforced the rule that extraction does not equal publication.
• Explicitly decided to keep the catalogue execution-derived for now and defer curated canonical patterns.
• Confirmed the end-to-end pipeline consistency from codebase extraction to rendered catalogue page.

Key trade-offs

• Adding agentic dimensions increased structural clarity but risked over-constraining the catalogue to multi-agent patterns.
• Hardening governance reduced ambiguity but added process overhead and corrective alignment work.
• Formalising lifecycle and publication rules improved integrity while slowing immediate pattern publication.
• Extending schemas before clarifying intent required retroactive adjustments to prevent misinterpretation.

What changed in my thinking

• Architectural metadata must describe context without implicitly enforcing architectural shape.
• Schema alignment across extractor, transformer, template, and runbook is itself a first-class architectural concern.
• Governance layers are necessary to prevent drift in AI-assisted knowledge systems.
• Explicit “unknown” values are safer than silent inference when capturing architectural signals.

Architecture signals (optional)

• Treat descriptive metadata as contextual, not prescriptive, unless explicitly intended.
• Separate extraction from publication to maintain catalogue integrity.
• Align schema, transformation logic, and rendering templates as a coordinated system.
• Use lifecycle states as guardrails against entropy in evolving knowledge artefacts.

Key takeaways

• Extraction and publication must be decoupled to protect quality.
• Descriptive architectural metadata should not become implicit constraints.
• Schema changes require coordinated updates across the full toolchain.
• Governance and lifecycle definitions reduce long-term drift.
• “Unknown” is a valid architectural state when evidence is incomplete.

Looking ahead (optional)

• Introduce lightweight compatibility checks when evolving schemas and templates in parallel.
• Consider adding versioning notes when extractor, transformer, and template evolve together.
• Periodically run an end-to-end test pattern to validate full pipeline integrity after structural changes.

Related learning threads this week

• Architecture signals & invalidated assumptions

Note: This Weekly Learning was produced using the Ideas to Life Weekly Learning system. See: Weekly Learning system map