Skip to content
Silent Potato.
SearchTagsEN/中文
  • Start
  • Writing
  • Columns
  • Projects
  • Research
  • Work with me
  • Photos
  • About

Research · preprint · 0.1

Data Measurement as Organizational Protocol: Definitions, Measurement, Tiering, and Retrospectives

A research-design and protocol paper: reframing data measurement from what belongs on the dashboard into a recomputable, reviewable, decision-supporting collaboration protocol, with minimal mechanisms for definitions, measurement units, metric tiering, dictionaries, and retrospectives.

LiyukLiyukPublished August 14, 2026
  • #Data
  • #Metrics
  • #Measurement
  • #Collaboration
  • #Reproducibility
  • #Technology
  1. 1The Five Lenses: Connection-Oriented Problem LocationDeep research · 19 min read
  2. 2Data Measurement as Organizational Protocol: Definitions, Measurement, Tiering, and RetrospectivesDeep research · 11 min readThis chapter
  3. 3Developer Productivity Is Not a Tool Catalog, but a Feedback SystemDeep research · 9 min read
  4. 4Defining the Boundaries Before Bringing AI Capability into an Engineering OrganizationDeep research · 9 min read
  5. 5When AI Lowers Workflow Barriers: How to Redivide Functional Lines and Business LinesDeep research · 14 min read
  6. 6Decompose First, Then Schedule: A Review of Multi-Model Task Decomposition, Capability Switching, and Subtask RoutingDeep research · 13 min read
  7. 7Making an Agent a Collaborable Object: State, Feedback, and Result ConfirmationDeep research · 13 min read
  8. 8Let the Agent Execute: Emotional Adaptation, Trust Calibration, and Human Relief from Execution PressureDeep research · 13 min read
  9. 9The Laws of Human Motivation: The Situational Motivation ModelDeep research · 29 min read
  10. 10AI Does Not Automatically Create Productivity: From Local Acceleration to System ValueShort · 5 min read

Share to

XWeiboTelegramWhatsAppLinkedInFacebook

WeChat

Scan with WeChat

Open this article on your phone, or forward it to a friend.

Enjoy this site?

orSubscribe via RSS
← PreviousDefining the Boundaries Before Bringing AI Capability into an Engineering Organization
Next →Developer Productivity Is Not a Tool Catalog, but a Feedback System
View the column “Engineering & AI Judgment”← Previous: The Five Lenses: Connection-Oriented Problem LocationNext: Developer Productivity Is Not a Tool Catalog, but a Feedback System →

Keep reading

Maybe related to this one.

  • ResearchDefining the Boundaries Before Bringing AI Capability into an Engineering OrganizationA position paper based on the author's experience driving AI infrastructure and pilots in a real engineering organization: it proposes four kinds of boundaries—context, responsibility, authorization, and measurement—and offers a falsifiable pilot protocol plus a minimal harness as a demonstration of putting them into practice.Read summary →

    same column · shared 1 tag

  • WritingData Measurement Guide (Part 1): Data Definitions Are the Interface of CollaborationMetrics are not numbers on a report; they are the shared language a team uses to describe the same thing. Only after defining the object, event, denominator, and time can data participate in decisions.Read on →

    shared 5 tags

  • WritingData Measurement Guide (Part 2): Define What You're Measuring Before Arguing About MetricsA publicly reusable metric dictionary: from requests and users to tasks, explaining how availability, error, latency, performance, and feedback data should be defined, combined, and interpreted.Read on →

    shared 4 tags

© 2018–2026 Liyuk. Built slowly, published openly.

ElsewhereGitHub ↗X ↗LinkedIn ↗Email ↗Links ↗Favorites ↗RSS ↗
CC BY-NC-SA 4.0