The Narrative Management Protocol (NMP) 1.0

The Narrative Management Protocol (NMP) 1.0 -A normative specification for managing project intent as a versioned artifact set

Abstract

Projects are commonly initiated through descriptive artifacts that express intent in natural language, such as proposals, presentations, or requirement documents. As projects progress, execution-focused artifacts are introduced, including plans, tickets, architectural documentation, and implementations. While effective for delivery, these artifacts do not provide a formal mechanism for preserving, evaluating, and deliberately evolving project intent, assumptions, constraints, and decisions over time.

This document specifies the Narrative Management Protocol (NMP) 1.0, a coordination protocol that defines how project intent is represented, structured, versioned, governed, evaluated, and revised throughout the project lifecycle. NMP treats intent as a first-class, versioned artifact set that remains authoritative independently of execution artifacts.

The protocol is independent of delivery methodology, organizational structure, and implementation technology. It defines mandatory artifact types, semantic invariants, governance responsibilities, evaluative checks, execution feedback mechanisms, operational flow, and conformance requirements. Normative requirements are expressed using RFC terminology.

1. Introduction

Project coordination relies on artifacts created at different stages of a project lifecycle. Early-stage artifacts capture intent, motivation, assumptions, and expected outcomes, typically in natural language. Later-stage artifacts focus on execution, tracking, and implementation and are optimized for operational concerns rather than semantic continuity.

Existing methodologies address parts of this lifecycle. Agile frameworks define delivery mechanics. User stories structure functional increments. Architectural decision records capture isolated technical rationale. Project initiation documents establish scope and governance at a point in time. Each contributes value, yet none defines a continuously maintained, authoritative representation of project intent that remains inspectable and deliberately evolvable as understanding changes.

In practice, intent, assumptions, constraints, and boundaries are distributed across documents, conversations, tickets, and individual memory. As projects grow in duration, scale, or stakeholder diversity, this distribution increases coordination cost and obscures decision traceability. Code and plans accumulate irreversible constraints that are poorly understood by non-implementing roles, while new requirements are introduced without a shared understanding of their narrative impact.

The Narrative Management Protocol addresses this gap by defining a coordination layer whose primary responsibility is meaning preservation. NMP does not optimize delivery. It ensures that what is being delivered remains explicitly defined, reviewable, and deliberately revised.

2. Scope and non-goals

2.1 Scope

NMP governs:

• Representation of project intent in structured natural language
• Explicit documentation of assumptions and constraints
• Capture of durable decisions and trade-offs
• Formal definition of scope boundaries and exclusions
• Admission of work based on narrative compatibility
• Structured revision of intent in response to execution feedback

2.2 Non-goals

NMP does not define:

• Delivery cadence, iteration models, or planning techniques
• Estimation, prioritization, or resource allocation methods
• Organizational hierarchy or approval chains
• Implementation patterns, architectures, or technologies
• Performance, cost, or schedule optimization

3. Normative references and conventions

3.1 RFC terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119 and RFC 8174.

3.2 Transparency and rationale

Narrative change practices SHOULD align with the transparency and explicit-rationale principles described in RFC 7282.

4. Terminology

Narrative
A structured, natural-language definition of a project’s purpose, scope, assumptions, constraints, decisions, exclusions, and open questions.

Narrative artifact
A versioned document governed by this protocol and subject to defined semantic invariants.

Narrative entry
A discrete, independently addressable unit within a narrative artifact.

Narrative state
The complete set of authoritative narrative artifacts at a specific revision.

Work item
Any proposed unit of work, including features, epics, refactors, or structural changes.

Narrative tension
A documented mismatch between execution reality and the current narrative state.

5. Version control requirements (normative)

5.1 All authoritative narrative artifacts MUST be stored in a system providing immutable history.

5.2 Any modification MUST result in a new narrative state.

5.3 Narrative changes SHOULD be reviewed prior to acceptance.

5.4 Authoritative narrative artifacts MUST NOT be modified outside the approved version control mechanism.

5.5 Each narrative state MUST be uniquely identifiable and referenceable.

6. Narrative quality, structure, and invariants (normative)

6.1 Minimum semantic granularity

Narrative artifacts MUST be decomposed into discrete narrative entries.
Each entry MUST address exactly one concern.

Dense prose combining multiple assumptions, decisions, or exclusions into a single entry is NOT PERMITTED.

6.2 Stable identifiers

Each narrative entry SHOULD have a stable identifier. These identifiers MAY be referenced by work items, tickets, or documentation.

6.3 Artifact-specific invariants

• Purpose statements MUST be outcome-oriented and MUST NOT describe implementation.
• Assumptions MUST represent unverified beliefs.
• Constraints MUST be externally imposed or non-negotiable within the current narrative state.
• Decisions MUST reject at least one alternative.
• Exclusions MUST be testable as “in scope” or “out of scope.”
• Open questions MUST be resolvable in principle and have an explicit trigger.

6.4 Narrative linting and validation (informative)

Automated or checklist-based validation is RECOMMENDED.
Conformance does NOT require automated detection of invariant violations; human review is sufficient.

7. Narrative artifact set (normative)

An NMP 1.0–compliant project MUST maintain the following artifacts.

7.1 Narrative Seed

Required fields:

• Purpose
• Primary actor
• Success criteria
• Initial boundaries

7.2 Assumptions and Constraints Register

Each entry MUST include:

• Statement
• Type
• Rationale
• Implications

7.3 Decisions and Trade-offs Log

Each entry MUST include:

• Context
• Alternatives considered
• Rationale
• Consequences

7.4 Exclusions and Non-goals

Explicit list of excluded capabilities.

7.5 Open Questions Register

Each entry MUST include:

• Question
• Relevance
• Owner
• Resolution trigger

7.6 Narrative Tension Log

Each entry MUST include:

• Description
• Affected narrative entries
• Evidence
• Required resolution action

8. Protocol flow (normative)

The following flow is logical, not temporal. Steps MAY occur iteratively or in parallel.

1. Origin artifact transformation
2. Constraint identification
3. Boundary formalization
4. Decision capture
5. Work admission
6. Narrative-first change handling
7. Execution feedback capture
8. Periodic narrative review

9. Evaluative checks (normative)

Before work admission, the following checks MUST be applied:

• Intent alignment check
• Constraint compatibility check
• Boundary consistency check
• Decision coherence check
• Assumption validity check

The assumption validity check MUST assess whether the work materially depends on assumptions that are outdated, unvalidated, or contradicted by evidence.

Failure of any check MUST result in narrative revision or work rejection.

10. Emergent Narrative Mode (normative)

10.1 Definition

Emergent Mode allows structured intent discovery when goals are not yet well-defined.

10.2 Rules

• Narrative Seed MAY be provisional.
• Entries MUST be marked as provisional.
• Durable decisions are prohibited.

A decision is considered durable if it materially constrains future solution space or introduces irreversible commitments.

10.3 Exit conditions

Emergent Mode MUST be exited before:

• External contractual commitments
• Irreversible architectural decisions
• Public delivery milestones

11. Governance and review (normative)

11.1 Narrative Owner

A Narrative Owner MUST be designated.

This role defines responsibility for narrative integrity, not organizational authority. NMP assigns accountability for coherence, not decision power over execution stakeholders.

11.2 Review requirements

• Narrative Seed changes MUST be reviewed by accountable stakeholders.
• Assumptions, constraints, and decisions SHOULD be reviewed by the Narrative Owner and impacted domains.
• Minor clarifications MAY be reviewed by a delegated subset.

Explicit acknowledgment is REQUIRED.

12. Acceptable version control mechanisms (informative)

Version control is a functional requirement. Acceptable mechanisms include:

• Distributed VCS
• Immutable document systems
• Append-only logs
• Change-controlled collaborative editors

Centralization is OPTIONAL. Traceability is REQUIRED.

13. Narrative fallibility and revision obligations (normative)

Narratives are hypotheses, not truths.

Projects MUST periodically reassess:

• Which assumptions are validated or falsified
• Which decisions were made under incomplete knowledge

Resistance to revision MUST be justified explicitly.

14. Worked example: full protocol walkthrough (informative)

Context

A regional healthcare provider seeks to reduce missed outpatient appointments.

Step 1: Narrative Seed v1

Purpose:
Reduce missed outpatient appointments by improving schedule reliability and patient follow-through.

Primary actor:
Clinic front desk staff.

Success criteria:

• Appointment creation under 30 seconds
• Clinic-level no-show rates measurable monthly

Initial boundaries:

• No medical record management
• No clinical decision support

Step 2: Assumptions and Constraints

A-01 (Assumption):
Clinics operate within a single time zone.
Rationale: Clinics are regionally scoped.
Implications: Scheduling logic does not handle cross-time-zone coordination.

C-01 (Constraint):
Patient data MUST be stored and processed within the EU.
Rationale: Regulatory requirement.
Implications: Hosting and vendors restricted to EU-compliant providers.

Step 3: Exclusions

E-01: Insurance claim processing
E-02: Billing automation
E-03: Clinical treatment recommendations

Step 4: Decision capture

D-01:
Context: Appointment scheduling across clinic locations
Alternatives considered:

• Multi-time-zone scheduling
• Per-clinic isolated scheduling

Decision:
Adopt per-clinic isolated scheduling.

Rationale:
Reduces complexity and error risk.

Consequences:
Multi-region clinic chains require separate tenants.

Step 5: Work admission attempt

Proposed work item:
“Add automated insurance claim submission.”

Checks:
Intent alignment: FAIL
Boundary consistency: FAIL

Outcome:
Work rejected.

Step 6: Narrative-first change handling

New requirement:
Clinics request automated appointment reminders.

Narrative updates:

• Purpose expanded to include reminder delivery
• New constraint added: telephony provider must be EU-compliant
• Decision recorded limiting reminders to outbound calls only

Only after revision is implementation admitted.

Step 7: Execution feedback

Observation:
Pilot clinic operates satellite locations across two time zones.

Narrative tension logged against A-01.

Resolution:
Assumption A-01 revised; scheduling decision reconsidered.

Step 8: Periodic review

Outcome:

• Assumption updated
• Open question added regarding multilingual reminders
• Narrative state incremented

15. Relationship to downstream processes

Narrative Management operates upstream of execution. Downstream artifacts MAY reference narrative entries but MUST NOT modify them directly.

16. Protocol capabilities and limitations

16.1 Capabilities

NMP 1.0 provides:

• Stable intent representation
• Traceable decision-making
• Controlled change admission
• Cross-role readability

16.2 Limitations

NMP 1.0 does not:

• Guarantee correctness
• Eliminate uncertainty
• Replace execution frameworks

17. Conformance and adoption (normative)

Conformance is binary.

Partial adoption is expected and valid.
Non-conformance does NOT imply misuse.
Only claims of NMP 1.0 compliance are invalid if requirements are unmet.

18. Conclusion

The Narrative Management Protocol 1.0 defines a disciplined, technology-independent coordination layer for managing project intent as a versioned narrative artifact set. By enforcing structure, explicit reasoning, revision obligations, and execution feedback integration, NMP preserves meaning independently of delivery mechanics.

Its purpose is not to optimize delivery speed, but to ensure that delivery remains aligned with an explicitly defined and deliberately evolved understanding of what the project is meant to achieve.

The Author

My name is Ramazan Yavuz. I am a tech founder and software developer working on the design and construction of complex software systems. My work focuses on how software is conceived, specified, and evolved over time, especially at the intersection of technical implementation, decision-making, and organizational reality. I am particularly interested in the structural problems that arise when intent, assumptions, and constraints are not made explicit, and in how clearer definitions can lead to more resilient and understandable software systems.

Originally published on Medium: https://ryavuz.medium.com/the-narrative-management-protocol-nmp-1-0-4b8bc4c5d802.