Library / Narrativization and Narrative Studies Principles Framework
Jump to passage
In this reading

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 02:22:15 UTC · snapshot created 2026-10-03 03:38:22 UTC · last check 2026-10-03 04:50:20 UTC

NSTD.4:5 - Archetypal Grounding

Worked slice: viewpoint without false agency

An architecture explanation says: “The database wants to protect consistency, while the service wants speed.” This personification can foreground a trade-off. For a reader diagnosing latency, however, the needed relation is how transaction and replication choices affect response time.

NarrativeViewpointRecord@ArchitecturePersonification:
  narrativeRenderingRef: ArchitectureExplanation@v1
  viewpointOrVoiceKind: didactic personification
  focalizedSourceStructureRef: consistency and latency trade-off across selected architecture structures
  narrativeFunction: make the trade-off memorable and traversable
  hiddenOrWeakenedSourceStructureRefs: actual component responsibility, decision record, measured characteristics
  agencyOrResponsibilityRisk: component metaphor may be read as actor agency or authority
  literalizationRepair: explain the commit condition and latency consequence; identify who can change the configuration if that action is proposed
  sourceReturnCondition: return to architecture description and decision record for authority

Before:

The database refuses to let the service move fast.

After:

In this configuration the database waits for replica acknowledgement before confirming a commit. That choice protects the required consistency but increases the service’s response time. To change the trade-off, consult the configuration decision and measured latency; the personification only helped introduce it.

This repair keeps the narrative value while protecting ontology. The viewpoint is a lens over selected source structures, not a new actor.

Worked slice: narrator and reader roles

A future-project scenario can speak from an imagined user’s viewpoint to expose possible consequences. Describe it as a scenario so readers can distinguish the proposed experience from an actual user’s report or consultation. For example:

NarrativeViewpointRecord@FutureUserScenario:
  viewpointOrVoiceKind: prospective scenario voice
  focalizedSourceStructureRef: expected use situation and system interaction
  narrativeFunction: expose usability and risk questions before design is final
  hiddenOrWeakenedSourceStructureRefs: actual user evidence, policy claim, safety claim
  agencyOrResponsibilityRisk: imagined voice is treated as real stakeholder authority
  literalizationRepair: mark as scenario hypothesis and route evidence to user research owner
  sourceReturnCondition: return to source assumptions and later evidence

Choosing a viewpoint repair

Keep wording that already makes the relevant action clear. If a viewpoint hides a needed relation, add that relation, change perspective or name the responsible participant. Mark a scenario or metaphor when the reader could otherwise rely on it as an observation. Replace the device if its effect depends on concealing a fact needed for the intended use.

To compare alternatives, try a short literal account or another viewpoint and ask what the reader can now recover. For the database case, the comparison is whether the reader can explain the wait and locate the configurable choice. For the future-user case, it is whether the reader distinguishes a proposed experience from observed user evidence. Use NSTD.6 when a declared quality result is needed; these diagnostic questions are not a second ordinal scale.

FPF owner teaching

Viewpoint selects and highlights structure for a use. An architect’s view, a narrator’s voice and a protagonist’s function can help recover different aspects of the same case. When a real agency, assignment, capability or responsibility claim matters, recover that claim separately under its applicable definition.

A technical story says “the architecture wants to reduce coupling.” The useful content may be a criterion favoring fewer dependencies under a stated trade-off. An architect or team makes the choice; a system-role assignment is a relation involving that participant, not the participant itself. An architecture decision records or expresses the choice rather than acting as its maker.

In a franchise continuation, a protagonist centers attention, while the chosen premises determine what action is plausible. “The Force guided the decision” may be a sufficient story-world explanation in one scene and leave a character’s motivation unclear in another. Use the intended plot and reader effect to decide whether another connection is needed.

In a homotopy explanation, a space, path, or loop may be written as if it “wants” to deform or “remembers” a hole. That can help intuition, but the focalized object is not an agent. The repair is to state the formal relation being highlighted and where the personification stops.

In live commentary, viewpoint may follow one player, coach or tactical unit. This can make the stream intelligible while hiding off-ball actions or an uncertain ruling. Qualify a blame or capability claim when the unseen action or later official correction could change it; no commentary record is required merely to say so.

Use a literalization rewrite ladder.

Risky phraseSafe if read asRepair if literal reading would be false
“The architecture wants…”Shorthand for a selected quality pressure.State the structural criterion or trade-off; name the decision-maker if the choice or responsibility is at issue.
“The paper proves…”The paper contains the claimed proof.If proof status is disputed or conditional, identify the argument and its unresolved step or premise.
“The model knows…”A shorthand whose relevant behavioral meaning is clear.State the claimed behavior, available information or tested capability when the wording would change reliance.
“The protagonist represents the system…”Reader-facing focalization.State which source structures the protagonist highlights and hides.
“The market punished…”A description of an aggregate outcome.Describe the observed change and distinguish an established mechanism from a conjecture when the explanation affects reliance.

Keep a necessary clarification close to the phrase. For example: “The architecture favors fewer dependencies under the selected trade-off.” If the figurative wording already conveys that relation unambiguously, no extra disclaimer is needed.

Use alternate viewpoint when one viewpoint hides a load-bearing source structure. A learner-facing story may first focalize the novice, then briefly switch to the maintainer who pays the cost of hidden coupling. A live commentary may follow the attacking player, then mark what the defensive line or official review could change. A future-scenario narrative may focalize a user, then return to the system owner for constraints and responsibility.

Filled viewpoint records:

NarrativeViewpointAgencyDiscipline@ArchitecturePersonification:
  viewpointOrVoice: teacher voice using personification
  focalizedObjectRef: selected architecture candidate
  revealedSourceStructureRefs: coupling pressure; cohesion target; interface exception
  hiddenOrWeakenedSourceStructureRefs: architect role assignment; decision record; telemetry
  narrativeFunctionTerms: "architecture wants" as memory aid
  personificationOrAgencyWording: architecture described as wanting fewer dependencies
  directOwnerRefs: architect role assignment; architecture decision; characteristic evaluation
  blockedAgencyOverread: architecture is not an agent and has no responsibility
  repairAction: add "more precisely" sentence naming characteristic pressure and decision owner
NarrativeViewpointAgencyDiscipline@FictionalProtagonistProbe:
  viewpointOrVoice: close protagonist viewpoint for private storycraft testing
  focalizedObjectRef: protagonist function in continuation route
  revealedSourceStructureRefs: character agency constraint; premise; causal plot support
  hiddenOrWeakenedSourceStructureRefs: alternative viewpoints; broader canon conflicts; publication rights
  narrativeFunctionTerms: protagonist; actant; motivation
  directOwnerRefs: source-pack and canon owner; agency and role owner when moral responsibility is claimed
  blockedAgencyOverread: protagonist centrality does not create moral permission or canon authority
  repairAction: record character action support and route rights and publication outside this DPF
NarrativeViewpointAgencyDiscipline@LiveCommentaryView:
  viewpointOrVoice: commentator follows attacking side under time pressure
  focalizedObjectRef: attacking player or unit
  revealedSourceStructureRefs: possession, pressure, chance creation
  hiddenOrWeakenedSourceStructureRefs: defensive shape, off-ball movement, official review
  narrativeFunctionTerms: "forced", "wanted", "could not"
  directOwnerRefs: event source owner; evidence owner for claims; ethics owner if blame or harm framing appears
  blockedAgencyOverread: live focalization is not settled blame or capability assessment
  repairAction: mark provisional interpretation and later source-return route

Before relying on a strong agency claim, resolve the actual ambiguity in the text. A compact explanation can identify the acting system, the decision or the limited metaphor. Use a record only when its later use warrants one; lowering every verb to “is presented as” would itself obscure real actions.