Article Review: Groups 10-12 — General Architecture, Data, and AI Patterns¶

Approach¶

Extracted sections relevant to our patterns, decisions, and potential improvements. Focused on what challenges or validates our existing architecture.

Articles Reviewed¶

Group 10: Architecture Patterns¶

Design Patterns e-book (Dr Milan Milanovic) — Classic pattern reference
7 Mistakes Software Architects Make (CloudWay) — Anti-patterns for architects
C4 Model (IcePanel) — Architecture diagramming at 4 levels

Group 11: Data Architecture¶

The DynamoDB Book (Alex DeBrie) — DynamoDB modeling, single-table design, strategies
Dataflow Architecture (CALEB/TDS) — Derived data views, eventual consistency, materialization

Group 12: AI Patterns¶

Building 17 Agentic AI Patterns (Fareed Khan) — Reflection, ReAct, Planning, Multi-Agent, Memory, etc.
Fixing 14 Complex RAG Failures with Knowledge Graphs (Fareed Khan) — Graph-enhanced RAG for complex queries

Group 10: Architecture Patterns — Audit Against Our Practices¶

7 Mistakes Software Architects Make → Mapping to Our Practices¶

Mistake	Description	Our Status
1. Speaking tech to business	Using jargon with stakeholders	Mitigated — ADRs use Context/Decision/Consequences format readable by non-technical stakeholders
2. Not caring about implementation	Architect loses touch with code	Actively mitigated — Our reference implementations document real code. Architecture repo links directly to patterns in production code
3. Seagull architect	Dive-bomb, criticize, disappear	Mitigated by design — Architecture repo provides continuous guidance, not periodic reviews. Skills and rules encode the architect's presence
4. Technical nuance over big picture	Optimizing 30ms while ignoring manual approval queue	Watch for this — Backlog items are mix of detailed (jitter) and strategic (Step Functions for sagas). Keep both balanced
5. Not aligning with business goals	Tech for tech's sake	Aligned — ADRs 005-010 map to EDRM stages (business capabilities). Every module exists because of a business need
6. Over-engineering	Perfect architecture delaying delivery	Rule 8 (Least Agency) addresses this — also our principle of "modules not microservices" (ADR-002) deliberately avoids over-decomposition
7. Confusing activity with impact	Meetings and docs without moving the needle	The risk of this architecture repo — must ensure it drives real improvements, not just documentation. BACKLOG.md is the accountability mechanism

Key takeaway: Mistake 6 (over-engineering) is the one most relevant to our ADR-based modernization. We've explicitly addressed this with ADR-002 (modules not microservices) and the strangler pattern (incremental, not big-bang). Mistake 7 is a meta-risk — this very architecture repo could become activity without impact if backlog items don't get implemented.

C4 Model → Architecture Diagramming¶

The C4 model defines 4 levels: Context (L1), Container (L2), Component (L3), Code (L4).

Mapping to our repo: - L1 Context — Our EDRM stage mapping + Rails integration view - L2 Container — Our reference implementation ASCII diagrams (e.g., ProcessorApi → extractor → SNS → loader → uploader) - L3 Component — Our core/ vs shell/ boundary diagrams within each module - L4 Code — Our pattern files with actual code examples

Finding: We use informal ASCII diagrams in reference implementations. C4 provides a standard vocabulary (System, Container, Component) that could make our diagrams more consistent.

Verdict: LOW priority. Our ASCII diagrams work. C4 formalization would be nice but isn't blocking anything.

Group 11: Data Architecture — Audit¶

DynamoDB Book → Relevance to documentextractor and PSM¶

We use DynamoDB in two places: - EDA Data Mining — DynamoDB for data mining state - PSM — Athena over S3 (not DynamoDB, but similar eventual consistency concerns)

Key DynamoDB concepts relevant to us: - Single-table design — Multiple entity types in one table with overloaded keys. We don't use this (we use MySQL per-case schemas), but it's relevant for eda-data-mining's DynamoDB. - DynamoDB Streams — Change data capture for reacting to state changes. Could be useful if we ever move PSM event tracking from S3/Athena to DynamoDB. - Condition expressions — Atomic conditional writes. The DynamoDB equivalent of our SELECT...FOR UPDATE for idempotency. Already used in eda-data-mining. - Implement data model at the boundary (Ch. 9.2) — Mirrors our hexagonal architecture: DynamoDB access logic belongs in shell/, not core/.

Verdict: Informational. No changes needed. DynamoDB patterns are correctly applied in our existing modules.

Dataflow Architecture → Derived Data Views and Eventual Consistency¶

The article describes a system where: - Sources of truth (normalized, authoritative) publish events - Derived data views (denormalized, optimized for queries) are materialized from events - Eventual consistency is managed through event ordering and idempotent materialization

Direct mapping to our architecture: - Source of truth = per-case MySQL schemas (exhibits, documents, processing_jobs) - Derived data views = Elasticsearch indexes (search), S3/Athena (PSM events), Nutrient annotations (view layer) - Materialization = Our SNS events trigger downstream consumers that update derived views

Finding: This validates our event-driven architecture's approach to data consistency. Our pipeline is a materialization system: raw documents → processed data (MySQL) → search index (ES) → view layer (Nutrient).

Key insight for ADR-008 (ES upgrade): Elasticsearch should be treated as a derived data view, not a source of truth. The materialization pipeline (document processing → ES indexing) should be idempotent and re-runnable from the MySQL source of truth. QLE (Query Language Engine) should query the derived view (ES), not the source of truth (MySQL).

Verdict: Validates ADR-008 design. Add "ES is a derived data view" framing to ADR-008.

Group 12: AI Patterns — Relevance to nextpoint-ai¶

17 Agentic AI Patterns¶

The 19 patterns (actually 19, not 17):

Pattern	Relevance to Nextpoint
Reflection	Useful for AI-assisted review — generate then self-critique
Tool Using	nextpoint-ai already uses tools (search, DB queries)
ReAct (Reason+Act)	Standard agent loop — think, act, observe
Planning	ADR-005 orchestration could use planning agents
PEV (Planner-Executor-Verifier)	Matches our Explore→Plan→Code→Commit workflow
Multi-Agent	Reference for future multi-agent review workflows
Episodic + Semantic Memory	Relevant to persistent case context in nextpoint-ai
Graph Memory	Relevant if we build knowledge graphs for case relationships
Dry-Run Harness	Useful for testing AI actions before execution

Most relevant for us: PEV (Planner-Executor-Verifier) maps directly to our SPARC workflow. The Verifier step (checking output against rules) is what our reviewing-architecture skill does.

RAG + Knowledge Graphs¶

The article identifies 14 RAG failure modes and how knowledge graphs fix them. The most relevant to Nextpoint:

Multi-hop reasoning failure — "Find all documents from custodian X that mention contract Y and were created before date Z" requires traversing relationships. Pure vector search fails here; knowledge graphs connect entities.
Temporal reasoning failure — eDiscovery is heavily temporal (production deadlines, document dates, privilege log timelines). Knowledge graphs with temporal edges handle this.
Entity disambiguation — "John Smith" in different documents may be different people. Knowledge graphs resolve entity references.

Verdict: Future reference for nextpoint-ai. If we expand beyond document summarization to cross-document analysis, knowledge graphs would address the multi-hop and temporal reasoning challenges inherent in eDiscovery. Not actionable now but worth noting for nextpoint-ai roadmap.

Summary: Audit Findings¶

Validated¶

7 Mistakes article validates our ADR practice, hexagonal boundaries, and incremental strangler approach
Dataflow architecture validates our event-driven materialization pipeline (MySQL → ES → Nutrient)
DynamoDB patterns correctly applied in eda-data-mining module
PEV agentic pattern maps to our SPARC workflow

New Insights¶

ES as derived data view — frame ADR-008 around materialization, not ES as primary store
Mistake 7 risk — architecture repo must drive implementation (BACKLOG.md), not just documentation
Knowledge graphs — future reference for nextpoint-ai cross-document analysis

No BACKLOG Changes¶

These articles validated our existing approach rather than finding gaps. The one insight (ES as derived view) is a framing improvement for ADR-008, not a code change.

Ask the Architecture ×

Ask questions about Nextpoint architecture, patterns, rules, or any module. Powered by Claude Opus 4.6.