This document flows with consistent structure across all three viewpoints! Each section follows the same pattern:
- Deconstructing the viewpoint
- Original list reference
- Atomic dimensions with definitions
- Composite description examples
- Mapping back to original concepts
- Complete framework summary
The coordinate system is now complete and consistent.
The goal is to break "WHERE" down into its fundamental, non-overlapping dimensions that can be combined to precisely describe any location in the system.
Let's start with the original WHERE list and apply our differentiation process:
Original WHERE List:
1. Local machine (your laptop/desktop)
2. Code editor (e.g., VS Code)
3. Command line / terminal (local or SSH)
4. GitHub web UI (repos, issues, PRs, projects)
5. CI/CD dashboard (where builds run & show status)
6. Cloud provider console (Linode / provider dashboard)
7. Staging environment (pre-production servers)
8. Production environment (live servers / cluster)
9. Documentation / knowledge-base site (internal docs UI)
10. Communication / planning tools (Slack/Zoho/Lark)
After differentiation, we can identify these orthogonal WHERE dimensions:
Definition: The spatial relationship between the actor and the resource. This is a binary, fundamental property.
- Local (on your immediate physical machine, where you are)
- Remote (on a machine that is not your own, not where you are, accessed via a network)
This is as pure as it gets. It answers the question: "Is it here, or is it there?"
Definition: The designated function of a deployed system context, defined by its use case and data.
- Development Environment
- Testing Environment (or QA)
- Staging Environment
- Production Environment
This list is also now pure. It answers the question: "What is this environment for?" It is completely separate from where that environment is hosted.
Definition: The specific application or UI presented to the user to perform tasks.
- Code Editor (e.g., VS Code, Vim)
- Terminal / Shell (e.g., bash, zsh)
- Version Control UI (e.g., GitHub, GitLab)
- CI/CD Platform UI (e.g., Jenkins, GitHub Actions)
- Cloud Provider Dashboard (e.g., Linode Manager, AWS Console)
- Documentation Hub (e.g., Wiki, Notion)
- Communication Channel (e.g., Slack, Teams)
This dimension represents the digital "room" you are in to perform work.
Using these dimensions, we can describe any location with pinpoint accuracy:
Instead of vague terms like "Staging Environment," we can be precise:
-
WHERE: [Remote] [Staging Environment] accessed via [Cloud Provider Dashboard]
- Example: Managing staging servers through Linode Cloud Manager
-
WHERE: [Local] [Development Environment] accessed via [Code Editor]
- Example: Writing code in VS Code on your laptop
-
WHERE: [Remote] [Production Environment] accessed via [Terminal / Shell]
- Example: SSH into production servers for maintenance
Let's see how the original list maps to these atomic dimensions:
- Local machine = [Local] [Development Environment] via [Terminal/Code Editor]
- Code editor = [Local/Remote] [Any Environment] via [Code Editor]
- Command line / terminal = [Local/Remote] [Any Environment] via [Terminal/Shell]
- GitHub web UI = [Remote] [Any Environment] via [Version Control UI]
- CI/CD dashboard = [Remote] [Any Environment] via [CI/CD Platform UI]
- Cloud provider console = [Remote] [Any Environment] via [Cloud Provider Dashboard]
- Staging environment = [Remote] [Staging Environment] via [Multiple Interfaces]
- Production environment = [Remote] [Production Environment] via [Multiple Interfaces]
- Documentation site = [Remote] [Any Environment] via [Documentation Hub]
- Communication tools = [Remote] [Any Environment] via [Communication Channel]
VIEWPOINT: WHERE
- Dimension 1: Proximity (Local, Remote)
- Dimension 2: Environment Purpose (Development, Testing, Staging, Production)
- Dimension 3: Tool Interface (Code Editor, Terminal/Shell, Version Control UI, CI/CD Platform UI, Cloud Provider Dashboard, Documentation Hub, Communication Channel)
This framework aligns perfectly with our WHAT and HOW structures:
- WHERE tells us where something happens across multiple location dimensions
- WHAT tells us what happens across multiple activity dimensions
- HOW tells us how it happens across multiple execution dimensions
The key insight is that "WHERE" cannot be captured in a single flat list but requires multiple orthogonal dimensions to avoid the semantic contamination originally detected.
The goal is to break "WHAT" down into its fundamental, non-overlapping dimensions that can be combined to precisely describe any activity in the system.
Let's start with the original WHAT list and apply our differentiation process:
Original WHAT List:
1. Author code (write code, modules)
2. Configure (set up configs, branch rules, envs)
3. Test (run tests, verify behavior)
4. Deploy / release (push to staging/prod)
5. Monitor & operate (logs, alerts, fix production issues)
6. Document (write docs, runbooks)
7. Review & merge (code review, approvals)
8. Research / investigate (explore unknowns, gather info)
After differentiation, we can identify these orthogonal WHAT dimensions:
Definition: The fundamental operation being performed on a system component.
- Create (write new code, documentation, infrastructure)
- Read (view logs, examine code, read documentation)
- Update (modify existing code, change configuration, edit docs)
- Delete (remove code, tear down infrastructure, archive)
- Execute (run tests, deploy, start services, run scripts)
This is the CRUDE model (Create, Read, Update, Delete, Execute) - a more complete version of CRUD for development workflows.
Definition: The type of digital object being acted upon.
- Code (source files, modules, scripts)
- Configuration (env vars, settings, branch rules, infra definitions)
- Infrastructure (servers, networks, databases)
- Documentation (docs, runbooks, knowledge base)
- Output Data (application data, test data, user data)
- Process (workflows, pipelines, procedures)
Definition: The stage in the development lifecycle where the activity occurs.
- Development (coding, local testing, prototyping)
- Integration (merging, CI, branch management)
- Verification (testing, QA, validation)
- Deployment (releasing to environments)
- Operations (monitoring, maintenance, troubleshooting)
- Planning (research, design, investigation)
Using these dimensions, we can describe any activity with pinpoint accuracy:
Instead of vague terms like "Monitor & operate," we can be precise:
-
WHAT: [Read] [Infrastructure] during [Operations] phase
- Example: Reading server logs in production
-
WHAT: [Create] [Code] during [Development] phase
- Example: Writing new feature code locally
-
WHAT: [Execute] [Process] during [Verification] phase
- Example: Running automated test suite in CI
Let's see how the original list maps to these atomic dimensions:
- Author code = [Create] [Code] during [Development]
- Configure = [Create/Update] [Configuration] during [Development/Operations]
- Test = [Execute] [Process] during [Verification]
- Deploy = [Execute] [Process] during [Deployment]
- Monitor & operate = [Read/Update] [Infrastructure] during [Operations]
- Document = [Create/Update] [Documentation] during [Development/Operations]
- Review & merge = [Read/Update] [Code/Process] during [Integration]
- Research = [Read] [Documentation/Code] during [Planning]
VIEWPOINT: WHAT
- Dimension 1: Action Type (Create, Read, Update, Delete, Execute)
- Dimension 2: Artifact Type (Code, Configuration, Infrastructure, Documentation, Data, Process)
- Dimension 3: Work Phase (Development, Integration, Verification, Deployment, Operations, Planning)
This framework aligns perfectly with our WHERE structure:
- WHERE tells us where something happens across multiple dimensions
- WHAT tells us what happens across multiple dimensions
- Together, they create a coordinate system for describing any part of the system
The key insight is that just like "WHERE" couldn't be captured in a single flat list, "WHAT" also requires multiple orthogonal dimensions to avoid the semantic contamination you originally detected.
The goal is to break "HOW" down into fundamental, non-overlapping dimensions that describe the manner or method of work execution.
Let's start with the original HOW list and apply our differentiation process:
Original HOW List:
1. Manual GUI interaction (clicking in web UIs)
2. Command-line scripts / CLI commands
3. Code-based automation (CI pipelines, IaC apply)
4. Pull request workflow (PR → review → merge)
5. Interactive editor work (typing in your IDE)
6. Runbook / step-by-step procedures (followed manually)
After differentiation, we can identify these orthogonal HOW dimensions:
Definition: The primary interface or mechanism through which work is performed.
- Graphical Interface (GUI clicks, forms, visual editors)
- Command-Line Interface (CLI commands, shell scripts)
- Code/Text Interface (direct editing of source files, configs)
- API/Programmatic (REST calls, SDK usage, automated scripts)
This dimension answers: "What is the primary interface I'm using to perform this work?"
Definition: The degree of human involvement in task execution.
- Manual (fully human-driven, step-by-step)
- Semi-Automated (human triggers automated process)
- Fully Automated (system-triggered, no human intervention)
- Assisted (tools provide guidance but human executes)
This dimension answers: "How much of this process is handled by machines vs. humans?"
Definition: The workflow or process structure governing the activity.
- Direct Execution (immediate, individual action)
- Review Workflow (submit → review → approve → execute)
- Pipeline/Staged (linear sequence of automated steps)
- Collaborative Session (multiple people working together in real-time)
- Scheduled/Batch (time-based or event-triggered execution)
This dimension answers: "What is the process flow or coordination mechanism?"
Using these dimensions, we can describe any method with pinpoint accuracy:
Instead of vague terms like "Code-based automation," we can be precise:
-
HOW: [API/Programmatic] [Fully Automated] with [Pipeline/Staged] coordination
- Example: CI/CD pipeline that automatically runs on git push
-
HOW: [Graphical Interface] [Manual] with [Review Workflow] coordination
- Example: Clicking through PR review and merge in GitHub UI
-
HOW: [Command-Line Interface] [Semi-Automated] with [Direct Execution] coordination
- Example: Running a deployment script that you trigger manually
Let's see how the original list maps to these atomic dimensions:
- Manual GUI interaction = [Graphical Interface] [Manual] [Direct Execution]
- Command-line scripts = [Command-Line Interface] [Semi-Automated] [Direct Execution]
- Code-based automation = [API/Programmatic] [Fully Automated] [Pipeline/Staged]
- Pull request workflow = [Graphical Interface] [Manual] [Review Workflow]
- Interactive editor work = [Code/Text Interface] [Manual] [Direct Execution]
- Runbook procedures = [Mixed Interface] [Manual] [Pipeline/Staged]
VIEWPOINT: HOW
- Dimension 1: Interaction Mode (Graphical, Command-Line, Code/Text, API/Programmatic)
- Dimension 2: Automation Level (Manual, Semi-Automated, Fully Automated, Assisted)
- Dimension 3: Coordination Pattern (Direct Execution, Review Workflow, Pipeline/Staged, Collaborative Session, Scheduled/Batch)
This framework aligns perfectly with our WHERE and WHAT structures:
- WHERE = The context across multiple location dimensions
- WHAT = The action across multiple activity dimensions
- HOW = The method across multiple execution dimensions
Now we can describe any system activity with pinpoint accuracy using coordinates from all three viewpoints:
Activity: Code Review Process
- WHERE: [Remote] [Version Control Platform UI]
- WHAT: [Read] [Code] during [Integration] phase
- HOW: [Graphical Interface] [Manual] with [Review Workflow] coordination
Activity: Production Deployment
- WHERE: [Remote] [CI/CD Platform UI]
- WHAT: [Execute] [Process] during [Deployment] phase
- HOW: [API/Programmatic] [Fully Automated] with [Pipeline/Staged] coordination
Activity: Local Development
- WHERE: [Local] [Code Editor]
- WHAT: [Create] [Code] during [Development] phase
- HOW: [Code/Text Interface] [Manual] with [Direct Execution] coordination
This gives us a precise, unambiguous language for describing any aspect of the development workflow. The semantic contamination you originally detected is eliminated because each viewpoint is now broken down into its atomic, orthogonal dimensions.