Building Your Subtractive Practice
To apply the Subtractive Triad to your own creative practice or organization:
Step 1: Choose Your First Layer (Human)
Start with implementation (DRY). This is the most concrete and actionable.
Before proceeding to artifact or system levels, establish the discipline of
eliminating duplication.
Step 2: Audit for Duplication (Human)
Examine your work for repetition:
- Code: Same logic in multiple places?
- Design: Same patterns solved differently?
- Process: Same explanation given multiple times?
Step 3: Unify Through Abstraction (Human + Agent)
Don't just copy-paste. Extract the pattern. Name it. Document why it exists.
Create shared components, design tokens, or written principles depending on medium.
Step 4: Move to Artifact Level (Human)
Apply Rams' question: "Does this earn its existence?"
For every element in your work, ask what would be lost if you removed it.
If the answer is "nothing" or "not much," remove it.
Step 5: Validate Against the Whole (Human)
Ask Heidegger's question: "Does this serve the whole?"
Does this component integrate with the larger system, or does it create
disconnection? Isolated excellence is failure.
Step 6: Institutionalize as Infrastructure (Human + Agent)
Don't let principles remain aspirational. Encode them:
- CSS tokens that enforce constraints
- Linting rules that catch violations
- Shared libraries that embody patterns
- Documentation that explains "why," not just "what"
Real-World Example: Applying the Triad to a Design System
Let's say you're building a design system for your organization:
// Implementation Level (DRY)
// Before: Color defined in 12 different component files
.button { background: #4353ff; }
.nav-item { border-color: #4353ff; }
.link { color: #4353ff; }
// After: Unified through tokens
:root {
--color-primary: #4353ff;
}
.button { background: var(--color-primary); }
.nav-item { border-color: var(--color-primary); }
.link { color: var(--color-primary); }
// Artifact Level (Rams)
// Before: 8 different button variants
<Button variant="primary" />
<Button variant="secondary" />
<Button variant="tertiary" />
<Button variant="ghost" />
<Button variant="outline" />
<Button variant="link" />
<Button variant="danger" />
<Button variant="success" />
// After: Only what earns existence
<Button /> // Default: primary action
<Button variant="secondary" /> // Lower emphasis
<Button variant="danger" /> // Destructive action
// Removed: ghost, outline, link (use semantic HTML instead)
// Removed: success (use confirmation feedback, not button color)
// System Level (Heidegger)
// Before: Button exists in isolation
<Button onClick={handleSubmit}>Submit</Button>
// After: Button serves form's purpose
<Form onSubmit={handleSubmit}>
<Input name="email" />
<Button type="submit">Submit</Button>
</Form>
// The button isn't primary; the form is. Button recedes into transparent use.Notice how each level builds on the previous:
- DRY: Unified color definition prevents drift
- Rams: Removed variants that don't justify their complexity
- Heidegger: Button serves form's purpose, not its own appearance
Creating Philosophy as Infrastructure
To make principles operational rather than aspirational:
// 1. Encode constraints as tooling
// .eslintrc.js
module.exports = {
rules: {
// Enforce DRY: catch magic numbers
'no-magic-numbers': ['error', { ignore: [0, 1] }],
// Enforce Rams: limit component complexity
'complexity': ['error', { max: 10 }],
// Enforce Heidegger: require semantic naming
'id-length': ['error', { min: 3, exceptions: ['id', 'i'] }],
},
};
// 2. Create generative systems
// scripts/generate-component.js
// Auto-generates components following Canon constraints
const template = (name) => `
import { useCanonTokens } from '@/design-system';
export function ${name}() {
const tokens = useCanonTokens();
return (
<div style={{
padding: tokens.spacing.md,
borderRadius: tokens.radius.lg,
}}>
{/* Content */}
</div>
);
}
`;
// 3. Document rationale, not just rules
// CANON.md
## Why We Don't Use Arbitrary Values
**Principle**: Every spacing value must come from the golden ratio scale.
**Rationale**: Arbitrary spacing (like `padding: 13px`) creates visual noise.
The golden ratio (1.618) produces naturally harmonious proportions that work
across scales without manual tuning.
**How to Apply**: Use tokens: `--space-xs`, `--space-sm`, `--space-md`, etc.
Never hardcode pixel values for spacing.When to Apply (and When Not To)
Apply the Subtractive Triad when:
- Starting a new system: Establish constraints early, before complexity accumulates
- Refactoring existing work: Use as lens to identify what to remove
- Onboarding new team members: Provides clear decision-making framework
- Experiencing drift: When implementations diverge, reconnect through shared principles
Don't apply when:
- Exploring genuinely new territory (premature abstraction is harmful)
- Working on throwaway prototypes (overhead not justified)
- The team lacks shared context (philosophy requires common language)
Measuring Subtractive Success
How do you know the Triad is working?
✓ DRY (Implementation): Changing a pattern updates all instances automatically
✓ Rams (Artifact): Team can explain why every element exists
✓ Heidegger (System): Components integrate seamlessly without custom glue code
✓ Infrastructure: Violations are caught by tooling, not code review
✓ Onboarding: New contributors understand constraints within first week
✓ Evolution: System ages well—additions feel coherent, not bolted-on
The ultimate test: Can you describe value without mentioning technology?
If your explanation requires implementation details, you're thinking additively.
Subtractive thinking reveals outcomes: "Meetings follow up on themselves"
not "SMTP integration with CRM webhooks."