Skip to main content

Proof / Decision Records

04 RECORDS · 01 METHOD

Proof

Project images show what was built. Decision records explain why it was built that way, what I owned and what the public evidence can actually support.

04
DECISIONS
01
METHOD
05
STAGES

00 Operating Method

Make the choice reviewable.

The same chain runs through every case: define the problem and boundary, structure the data, choose the model, deliver the system and verify the result.

  1. 问题 Problem
  2. 数据 Data
  3. 模型 Model
  4. 系统 System
  5. 验证 Verify

01–04 Decision Records

Four decisions.
Four explicit trade-offs.

  1. 01

    Business Intelligence

    Contract Profitability Management System

    Constraint
    Revenue, cost, collection and delivery data were split across systems with inconsistent definitions, while every management indicator still needed a path back to its source.
    Alternatives considered
    1. 01 Continue assembling monthly reports
    2. 02 Reconcile the logic inside the BI layer
    3. 03 Govern the definitions first and build a contract-level operating model
    Why this choice
    Defined the metrics and ownership boundaries first, used the contract as the central key, and kept complex calculation logic in the governed model rather than the presentation layer.
    My contribution
    Led metric governance, the contract-level model, warehouse layers, dashboard design and acceptance rules while aligning business, finance and IT stakeholders.
    Result and reuse value
    Created a traceable path from management indicators to contracts, projects and cost sources, with a reusable structure for adding future operating views.
    Public evidence boundary
    The public interface is reconstructed from the implemented business structure using demonstration data. Company, customer, contract and financial identifiers are not disclosed.
    View full case
  2. 02

    Digital Transformation

    Digital Operations Analytics for Industrial Services

    Constraint
    Monthly reporting was slow and different management roles needed different views, while the underlying metric definitions had to remain consistent across every interface and delivery phase.
    Alternatives considered
    1. 01 Keep adding one-off reports
    2. 02 Buy a dashboard tool before resolving the data foundation
    3. 03 Let governed metrics drive the data foundation and role-specific views
    Why this choice
    Chose a metric-first sequence: establish a maintainable dictionary, build the pipeline and warehouse layers, then deliver decision views by management role.
    My contribution
    Owned the program plan, metric system, delivery priorities and visualization while translating continuously between operating language and data architecture.
    Result and reuse value
    Shifted management discussion away from reconciling numbers toward interpreting operations, with a structure that can expand by subject and role.
    Public evidence boundary
    The public view is an anonymized reconstruction of the implemented structure. Organization names, platform states and operating data are demonstration content rather than live production values.
    View full case
  3. 03

    AI Engineering

    Local-first AI Agent Workspace

    Constraint
    Sensitive data could not be exported by default. Local models varied in quality and speed, stronger cloud models still had legitimate uses, and the toolchain needed to remain replaceable.
    Alternatives considered
    1. 01 Route every task to cloud models
    2. 02 Operate entirely offline
    3. 03 Route by data boundary and task difficulty
    Why this choice
    Chose a local-first layered architecture in which local runtimes handle routine work, a gateway owns model and tool routing, and only necessary tasks leave the device after data minimization.
    My contribution
    Independently designed model selection, runtime configuration, routing rules, tool orchestration, agent workflows and failure recovery, then calibrated the system with real tasks.
    Result and reuse value
    Routine work stays local while difficult tasks can still reach stronger models. Models and tools remain replaceable rather than locking the workflow to one provider.
    Public evidence boundary
    The public interface is reconstructed from the real toolchain and excludes local paths, accounts, conversations, document contents and private data.
    View full case
  4. 04

    AI Engineering

    Engineering Evaluation System for AI Tools

    Constraint
    Tools changed quickly, marketing noise was high, subjective impressions were not reproducible, and public leaderboards did not represent reliability or integration cost in real engineering work.
    Alternatives considered
    1. 01 Follow popularity and anecdotal recommendations
    2. 02 Use public leaderboards alone
    3. 03 Evaluate fixed scenarios with stable dimensions and versioned records
    Why this choice
    Built a standard task set from real work, fixed the process and dimensions, changed only the tool under test, and recorded both failure boundaries and appropriate contexts.
    My contribution
    Designed the method, tasks, record format and comparison dimensions, ran the evaluations, and separated public observations from personal judgment and unverified conclusions.
    Result and reuse value
    Turned tool preference into a traceable selection process that eliminates poor workflow fits earlier and preserves changes across versions.
    Public evidence boundary
    The public interface is reconstructed from the actual evaluation dimensions. Displayed scores illustrate the record structure and are not a published benchmark or third-party performance claim.
    View full case