Skip to content

Introduced by a trusted connector?

Start Here

Anthony Veltri

  • Doctrine
    • Doctrine Library
    • Global Library
  • Field Notes
  • Routes
    • Route 01: When the Interface Is Breaking (and you are becoming the patch)
    • ROUTE 02: If decisions stall and meetings go nowhere, start here
    • ROUTE 03: If you have lots of projects but no portfolio clarity, start here
    • ROUTE 04: If you’re confused about federation vs integration, start here
    • ROUTE 05: If heroics are propping up your system, start here
    • ROUTE 06: If you cannot force compliance across partners, start here
    • ROUTE 07: If compliance exists but commitment does not, start here
    • ROUTE 08: If disconnected workflows create audit anxiety, start here
  • Figure Library
  • FAQ
  • About
    • Capability Statement
    • Interpreter Kit
  • Contact
Anthony Veltri

Architecture & Interfaces

15
  • Doctrine 01: Federation vs Integration in Mission Networks
  • Doctrine 03: Interfaces Are Where Systems Break, So They Require Stewards, Contracts, and Ownership
  • Doctrine 04: Useful Interoperability Is the Goal, Not Perfect Interoperability
  • Doctrine 05: Innovation Must Live at the Edge, Not in the Center
  • Doctrine 06: A Two-Lane System Protects Stability and Enables Evolution
  • Doctrine 14: Technical Debt Is a Leadership Signal, Not a Coding Failure
  • Doctrine 15: Architecture Must Accelerate Teams, Not Bottleneck Them
  • Doctrine 17: Architects Translate Strategy Into Engineering and Engineering Into Strategy
  • Doctrine 20: Golden Datasets: Putting Truth In One Place Without Pretending Everything Is Perfect
  • Doctrine 21: Zero Trust Is A Trust Model, Not A Card “Type”
  • Doctrine 23: Loop Closure as Load-Bearing System Infrastructure
  • ANNEX B. Data Contracts
  • ANNEX C. Interface Ownership Model
  • ANNEX H. Architecture Doctrine
  • Annex L: The Rosetta Stone for Data Teams: Bridging the Gap Between Technicians and Executives

Decision Tempo & Governance

10
  • Doctrine 02: Distributed Decisions Increase Alignment, Speed, and Resilience
  • Doctrine 07: Clear Intent Matters More Than Perfect Data
  • Doctrine 08: Clear Intent Compresses Ambiguity, Reduces Conflict, and Accelerates Action
  • Doctrine 09: Decision Drag Is the Enemy of Mission Tempo. Architecture Is the Remedy
  • Doctrine 10: Degraded Operations Are the Normal Mode, Not the Exception
  • Doctrine 11: Preventive Action and Contingent Action Must Both Be Designed Intentionally
  • Doctrine 22: When “It Depends” Is the Right Answer: How to Think in Probabilities Under Uncertainty
  • ANNEX D. Decision Altitudes Model
  • ANNEX E. Prevention–Contingency Matrix
  • ANNEX I. High Visibility Workflows

Portfolio & Alignment

4
  • Doctrine 16: Portfolio Thinking Ensures Effort Aligns With What Actually Matters
  • ANNEX F. Pattern Library
  • ANNEX J. System Evolution and Drift Management
  • ANNEX K. System and Workflow Profiles (Case Studies)

Leadership & Human Systems

6
  • Doctrine 24: Stewardship Places the Burden on the Steward, Not the Parties
  • Doctrine 18: Commitment Outperforms Compliance in High Trust, High Tempo Environments
  • Doctrine 19: Supervision, Management, and Leadership Are Three Different Jobs. Confusing Them Breaks Systems
  • Doctrine 23: Loop Closure as Load-Bearing System Infrastructure
  • ANNEX A. Human Contracts
  • ANNEX G. Leadership Doctrine

Resilience & Operations

3
  • Doctrine 24: Stewardship Places the Burden on the Steward, Not the Parties
  • Doctrine 12: Resilience Is an Emergent Property, Not a Feature
  • Doctrine 13: Problem Solving Requires Finding the Real Deviation and the Relevant Change

Doctrine Companions

7
  • Doctrine 03 Companion: The RS-CAT Framework: Converting Raw Recall into Teachable Principle
  • Doctrine 03 Companion: The Interface Void
  • Doctrine 11 Companion: Agency vs. Outcome
  • Doctrine 09 Companion: Artifacts Over Adjectives
  • Doctrine 03 Companion: Constraints: bidirectional translation: Compression vs Construction
  • Doctrine 10 Companion: Span of Control and Cross Training Are Load-Bearing Constraints
  • Doctrine 21 Companion: Claims, Roles, and Entitlements in Microsoft 365

Field Reports

1
  • Field Report: College Financing and the 5-Year Home Runway
View Categories
  • Home
  • Doctrine & Supporting Guides
  • Decision Tempo & Governance
  • Doctrine 07: Clear Intent Matters More Than Perfect Data

Doctrine 07: Clear Intent Matters More Than Perfect Data

Anthony Veltri
Updated on December 9, 2025

4 min read

Why missions fail without intent, even when the data are perfect #

This page is a Doctrine Guide. It shows how to apply one principle from the Doctrine in real systems and real constraints. Use it as a reference when you are making decisions, designing workflows, or repairing things that broke under pressure.

This Doctrine guide is the manifesto for Action over Paralysis. It argues that “Intent” is a functional substitute for “Data” when the clock is ticking.

Perfect data never arrives on time #

A flowchart compares early and delayed decisions. Early decision (left) leads to 3 actions; delayed decisions (right) lead to 11+ actions, more risks, costs, and dependencies. Text below states delays multiply work.
The Cost of Waiting. Waiting for perfect data is not free. It exponentially increases the dependencies and effort required to achieve the same result later.

If you wait for perfect data, you will make perfect decisions too late.

In mission systems, the world moves faster than your inputs.
Conditions change. Partners lag. Models drift. Networks degrade.
Intent is what lets a team act decisively even when the information picture is incomplete.

Intent is the anchor.
Data is the accelerant.


Lived Example: The day the “perfect” flood model was useless #

A flowchart titled "Bayesian Updating – Learning As You Go" shows four steps: Prior, Evidence, Updated Estimate, and Action, each with icons and brief descriptions illustrating how new evidence updates decisions.
Iteration Over Perfection. You do not need 100% certainty to start. You need a prior estimate, an action, and a feedback loop to update the picture as you go.

During a severe weather activation, we had access to an extremely detailed flood model that had been trained, tuned, and validated for years.
It delivered near perfect predictions at test time.

But on the day of the activation:

  • a tributary failed upstream
  • a levee breach redirected flow
  • partner data feeds lagged
  • field teams could not confirm ground truth for hours
  • satellite passes were delayed due to cloud cover

The model was perfect for last year.

Intent was what mattered that day.

Our team had clear priorities:

  • protect evacuation routes
  • preserve hospital access
  • maintain logistics corridors
  • focus on life safety first

Those priorities let us act even as data was catching up.

Intent carried the mission.
Data followed.


Business Terms: What intent does #

Clear intent:

  • tells teams what outcome matters most
  • guides decisions when input is incomplete
  • reduces escalation
  • creates alignment without requiring a meeting
  • lowers cognitive load
  • avoids decision drag
  • Empower partners to act under ambiguity

Perfect data cannot do any of this.

Intent communicates what to optimize for.
Data only communicates what the world looks like right now.


System Terms: How intent stabilizes complex environments #

Infographic comparing centralized (single point of failure) with distributed (flow at the edge) decision-making. Centralized shows bottlenecks and overload; distributed shows quick, local decisions guided by intent and constraints.
Intent Enables Flow. Without intent (Red), every decision must route to the center for data validation. With intent (Green), the center sets constraints, and the nodes can act immediately on local data.

In system language, intent is:

  • the top-level constraint
  • the north star
  • the governing objective
  • the priority function applied to every decision node
  • the meta-signal that aligns distributed agents

Without intent:

  • agents optimize for local goals
  • the system develops unintended behavior
  • coordination saturates
  • decision drag explodes
  • data gets over weighted
  • changes ripple unpredictably

With intent:

  • distributed decisions converge on shared priorities
  • autonomy becomes safe
  • variance becomes productive rather than chaotic
  • asynchronous operations maintain coherence

Intent is a stabilizer.
Data is an input.


Why “waiting for the perfect picture” fails #

Business perspective #

Perfect data is a trap because:

  • it arrives too late
  • it requires too many approvals
  • it depends on infrastructure that fails under stress
  • it gives a false sense of certainty
  • it delays action until the window of impact has closed
  • partners feel blocked waiting for the “official” view

If you wait for the full picture, you lose the ability to shape the picture.

System perspective #

Perfect data is impossible because:

  • sensors drift
  • feeds lag
  • schemas evolve
  • partners publish asynchronously
  • maps do not match ground truth
  • edge cases dominate
  • models degrade out of distribution

Systems built around perfect data collapse under real conditions.


Why clear intent wins every time #

Business perspective #

Clear intent:

  • aligns teams without needing perfect information
  • reduces rework
  • lowers friction
  • reduces email chains
  • speeds up approvals
  • lets partners act independently
  • clarifies what not to do
  • reduces political conflict

Teams need to know the mission, not every number.

System perspective #

Intent is the optimization function.

It allows:

  • distributed local action
  • safe autonomy
  • degraded mode operation
  • resilience under partial failure
  • consistent behavior despite variable inputs

Intent gives systems coherence when data is incomplete.


Business Example: When a GIS outage did not stop mission tempo #

Timeline showing three stages: Crisis Request Arrives, Adaptive Lane Response, and Stable Lane Integration, connected by arrows. Each stage lists key actions for responding to and resolving a crisis request.
Crisis Request –> Adaptive Response (Hours) –> Stable Integration (Later). Intent Fills the Gap. When the stable data feed fails, intent allows the team to shift instantly to an adaptive response (manual coordination, radio, local maps) without freezing.

During a multi-day activation, a key GIS service went down due to a regional infrastructure issue.
Without that layer, some teams thought activity had to pause.

But because our intent had been clearly communicated:

  • protect critical corridors
  • preserve access to special facilities
  • prioritize vulnerable populations

Teams acted quickly with what they had, not what they wished they had.
They used local maps, field calls, radio updates, and human judgment.

Mission tempo never slowed.
Intent filled the gap left by missing data.


System Example: iCAV and the “minimum viable picture” #

In USDHS’s iCAV, the harmonization layer often received incomplete, out-of-date, or asynchronously published feeds from partners.

If the system required all feeds to be current, it would fail regularly.

Instead:

  • intent drove which feeds were prioritized
  • the system displayed partial truth when full truth was unavailable
  • stale layers were marked but still shown
  • caching preserved the last known good view
  • degraded operation modes were intentional

This allowed decision makers to work with partial data while preserving situational awareness.

Intent guided the system.
Not perfection.


Architect Level Principle #

As an architect I design systems around intent, not perfection.
Intent enables distributed action under uncertainty.
Data accelerates intent, but it cannot replace it.


In Summary: #

Perfect data never arrives on time. Intent gives teams clarity on what to do even when the picture is incomplete. In mission environments, I design around intent first and data second, because intent keeps decisions aligned when conditions change, feeds lag, or models drift.


Cross Links to Other Principles #

This principle directly connects to:

  • Distributed decision making
  • Degraded operations
  • Resilience as emergent
  • Two-lane systems
  • Decision drag
  • Portfolio thinking
  • Innovation at the edge

Each relies on intent as a stabilizing force.


Doctrine Diagnostic – For Reflection: #

Ask yourself:

If your data feed went dark for an hour (or whatever tempo is important to you), could your team still act?
If the answer is no, you are optimizing for data, not intent.

Fix that.

Field notes and examples #

  • Field Note: Snake or Stick?!
  • Guarding the Room: A Hubbard Brook Story About Science and Funding
  • Human Contracts Under The Air Picture

Last Updated on December 9, 2025

Related Posts #

A geometric abstract design with circles, lines, and shapes in muted colors. Overlaid text reads:

Doctrine 08: Clear Intent Compresses Ambiguity, Reduces Conflict, and Accelerates Action #

A graphic with the text

Doctrine 04: Useful Interoperability Is the Goal, Not Perfect Interoperability #

This diagram illustrates increasing salary capacities, with larger houses on higher blocks representing $6k, $24k (median), and $80k per year.

Field Report: College Financing and the 5-Year Home Runway #

Thinking in Probabilities featured title card

Doctrine 22: When "It Depends" Is the Right Answer: How to Think in Probabilities Under Uncertainty #

A graphic with abstract circuit-like patterns and geometric shapes. Large text reads

ANNEX H. Architecture Doctrine #

ANNEX F Pattern Library" text over a background of interconnected geometric lines, circles, and digital patterns resembling a circuit or network schematic.

ANNEX F. Pattern Library #

contracts, decision-tempo, degraded-ops, governance, technical-debt
Table of Contents
  • Why missions fail without intent, even when the data are perfect
  • Perfect data never arrives on time
  • Lived Example: The day the “perfect” flood model was useless
  • Business Terms: What intent does
  • System Terms: How intent stabilizes complex environments
  • Why “waiting for the perfect picture” fails
    • Business perspective
    • System perspective
  • Why clear intent wins every time
    • Business perspective
    • System perspective
  • Business Example: When a GIS outage did not stop mission tempo
  • System Example: iCAV and the “minimum viable picture”
  • Architect Level Principle
  • In Summary:
  • Cross Links to Other Principles
  • Doctrine Diagnostic - For Reflection:

Share This Article :

  • Facebook
  • X
  • LinkedIn
  • Pinterest

Was it helpful ?

  • Happy
  • Normal
  • Sad
  • Privacy Policy
  • Introductions
  • Contact

© 2026 Anthony Veltri

  • Doctrine
    • Doctrine Library
    • Global Library
  • Field Notes
  • Routes
    • Route 01: When the Interface Is Breaking (and you are becoming the patch)
    • ROUTE 02: If decisions stall and meetings go nowhere, start here
    • ROUTE 03: If you have lots of projects but no portfolio clarity, start here
    • ROUTE 04: If you’re confused about federation vs integration, start here
    • ROUTE 05: If heroics are propping up your system, start here
    • ROUTE 06: If you cannot force compliance across partners, start here
    • ROUTE 07: If compliance exists but commitment does not, start here
    • ROUTE 08: If disconnected workflows create audit anxiety, start here
  • Figure Library
  • FAQ
  • About
    • Capability Statement
    • Interpreter Kit
  • Contact