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.

86
Articles
0
Likes
24
Views
0
Comments
Recent Articles

Latest from Data Bricklaying Diary

86 recent articles
Data Bricklaying Diary
Data Bricklaying Diary
Sep 8, 2026 · R&D Management

From Wiki to Execution: Making Organizational Knowledge Work for AI Agents

The article explains why organizational rules stored in wikis fail to constrain AI agents, and presents a five-layer framework—project context, reusable skills, event-driven hooks, CI gates, and platform policies—to embed knowledge directly into agent execution paths, with versioning, ownership, and gradual rollout practices.

AI agentsAgent ExecutionCI/CD
0 likes · 14 min read
From Wiki to Execution: Making Organizational Knowledge Work for AI Agents
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.

KnowledgeOpschange managementcompatibility
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.

canary deploymentdependency managementdistributed systems
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.

Data Governanceaudit trailbusiness schema
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.

agent negotiationchange routingdynamic ontology
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.

agent negotiationdynamic ontologyindustrial AI
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