BestHub
Sign in
Data Bricklaying Diary
Author

Data Bricklaying Diary

Records practices, thoughts, and pitfalls on the data grunt-work journey, sharing content on data platforms, data analysis, data processing, data governance, knowledge graphs, and more. Less theory, more hands‑on, making complex data technologies simple.

165
Articles
0
Likes
383
Views
0
Comments
Recent Articles

Latest from Data Bricklaying Diary

100 recent articles max
Data Bricklaying Diary
Data Bricklaying Diary
Sep 8, 2026 · Fundamentals

Ontology Isn't a One-Time Deliverable: Versioning, Change Management & Feedback Loops

This article explains why ontologies must be treated as continuously operated semantic baselines rather than static deliverables, detailing four version axes, change set governance, cross-layer impact analysis, compatibility verification, migration strategies, and a feedback loop that attributes runtime signals before correcting the model, illustrated with a credit-risk case study.

Change ManagementFeedback LoopKnowledgeOps
0 likes · 30 min read
Ontology Isn't a One-Time Deliverable: Versioning, Change Management & Feedback Loops
Data Bricklaying Diary
Data Bricklaying Diary
Sep 7, 2026 · Backend Development

Independent Deployment ≠ Independent Evolution: Designing Dependencies, Routing & Release Architecture

The article explains why independent deployment doesn't guarantee independent service evolution, detailing five required capabilities—identifiable dependencies, compatible interfaces, controllable traffic routing, verifiable releases, and recoverable failures—using a refund service case study to illustrate dependency topology, interface evolution patterns, phased release strategies, and evidence-based rollback decisions.

Release EngineeringRollback Strategycanary deployment
0 likes · 21 min read
Independent Deployment ≠ Independent Evolution: Designing Dependencies, Routing & Release Architecture
Data Bricklaying Diary
Data Bricklaying Diary
Sep 7, 2026 · R&D Management

Why Enterprise AI Struggles to Adopt Frontline Experience: Build a Knowledge Collaboration Loop First

This article argues that enterprise AI projects fail not from poor ontology modeling but from lacking a knowledge collaboration loop where frontline judgments are captured with context, verified by authorized roles, transformed into testable assets, and continuously refined through operational feedback — without transferring accountability from experts.

enterprise AIfeedback loopsfrontline experience
0 likes · 25 min read
Why Enterprise AI Struggles to Adopt Frontline Experience: Build a Knowledge Collaboration Loop First
Data Bricklaying Diary
Data Bricklaying Diary
Sep 6, 2026 · Fundamentals

Standard Ontologies Aren't Business Schemas: How to Map Changing Terms to Stable Models

The article argues that standard ontologies and business schemas serve distinct roles—ontologies provide standard concepts while schemas offer stable application contracts—and a normalization layer must connect raw terms to both using evidence, context, versioning, and review status, because similarity scores only produce candidates, not confirmed facts.

Audit Trailbusiness schemadata governance
0 likes · 16 min read
Standard Ontologies Aren't Business Schemas: How to Map Changing Terms to Stable Models
Data Bricklaying Diary
Data Bricklaying Diary
Sep 5, 2026 · Backend Development

Why Dynamic Ontologies Need Four Separate Governance Paths, Not One Auto-Update Button

The article argues that dynamic ontologies must route four distinct change types — terminology mapping, model evolution, runtime state, and agent negotiation — through separate governance paths with dedicated verification, release, and failure handling, rather than funneling all changes through a single auto-update mechanism, to preserve stable baselines, action contracts, and audit trails.

Governanceagent negotiationchange routing
0 likes · 16 min read
Why Dynamic Ontologies Need Four Separate Governance Paths, Not One Auto-Update Button
Data Bricklaying Diary
Data Bricklaying Diary
Sep 4, 2026 · R&D Management

Why AI-Native Development Needs an Executable Artifact Chain, Not More Specs

The article argues that in AI-native development, value lies not in generating more specification documents but in creating a traceable artifact chain linking business intent, requirements, design, plans, code, and evidence — with clear authoritative sources, state management, and dependency-based invalidation propagation to prevent agents from working on stale rules.

AI-native developmentArtifact ChainEntry-Exit Criteria
0 likes · 14 min read
Why AI-Native Development Needs an Executable Artifact Chain, Not More Specs
Data Bricklaying Diary
Data Bricklaying Diary
Sep 4, 2026 · Artificial Intelligence

Dynamic Ontology: Four Change Types That Must Not Share One Auto-Update Mechanism

The article distinguishes four distinct dynamics in ontology systems — terminology mapping, model evolution, runtime state, and agent negotiation — each with separate lifecycles, authorities, and validation requirements, warning against conflating them into a single auto-update mechanism.

Ontology Governanceagent negotiationdynamic ontology
0 likes · 18 min read
Dynamic Ontology: Four Change Types That Must Not Share One Auto-Update Mechanism
Data Bricklaying Diary
Data Bricklaying Diary
Sep 3, 2026 · R&D Management

AI Coding Accelerates, But R&D Process Emerges as New Bottleneck

As AI speeds up code generation, bottlenecks shift from coding to requirements clarity, design validation, verification evidence, and release accountability; the article argues for an AI-native SDLC built on authoritative artifacts, independent evidence, risk-based responsibility gates, and production feedback loops rather than simply adding agents to each phase.

AI-Native SDLCR&D ProcessSpec-Driven Development
0 likes · 12 min read
AI Coding Accelerates, But R&D Process Emerges as New Bottleneck
Data Bricklaying Diary
Data Bricklaying Diary
Sep 2, 2026 · Backend Development

Independent Deployment ≠ Clean Internals: Isolating Business Rules from Technical Details

This article explains why independently deployed services can still have chaotic internal architecture, and demonstrates how to separate business rules, use cases, ports, and adapters to ensure dependencies point inward, enabling testable, evolvable systems without mechanically applying layered templates.

business rules isolationclean architecturedependency inversion
0 likes · 22 min read
Independent Deployment ≠ Clean Internals: Isolating Business Rules from Technical Details