Requirements: WRSPM, Emotional Clarity, and Designing GRIOT with Intention

Introduction

In Post 0, I shared the seed that planted this journey: the vision of Shuri’s lab in Black Panther, where tech isn’t just functional—it’s sacred, rooted in memory, purpose, and care.

That vision pushed me to ask:

What if I built something like that? Something deeply personal. Something honest.

Most apps today are built to be used, discarded, and forgotten.
But what if you built something to remember?

What if software could serve as a witness?
What if it could reflect back who you’ve been, what you’ve survived, and where you’re trying to go?

That’s the question at the heart of GRIOT.

This is not just another side project or feature sprint.
It’s my attempt to build something sacred — a personal log and memory system that honors voice, rhythm, presence, and truth. Inspired by West African griots, Shuri’s AI interfaces in Black Panther, and my own journey of healing and clarity, GRIOT is a system designed to listen and grow with its user.

But even human-centered systems need structure.

That’s where WRSPM comes in — a technical framework for defining the World, Requirements, Specifications, Programs, and Machine. In this post, I’ll walk through how I’m applying WRSPM to GRIOT, not just to organize the codebase but to root every feature in intention.

This is the beginning of my engineering diary — a quiet, grounded design journal for the kind of tech I want to see more of: personal, precise, and built with care.

What is WRSPM (and why it matters)?

Most of us are taught to start a software project with the what — what stack we’ll use, what screens we’ll design, what features to build. But intentional, reflective systems don’t begin with what. They begin with why, who, and what this system even needs to exist for in the first place.

That’s where WRSPM comes in.

WRSPM stands for World, Requirements, Specifications, Program, Machine. It’s a layered model that helps engineers build software with clarity, starting from a real-world need and moving down to the actual code.

Here’s a breakdown of what each layer means:

  • World: The real-world context or environment the system lives in. What’s happening in that world that calls for a system? The world assumptions which are used to develop that system
  • Requirements: What must the system do to make a meaningful change in that world? Defining the existing problem the system is trying to solve in terms of a user of the system.
  • Specifications: A formal outline of how the system will behave to meet those requirements. Defining the technical requirements of the system. Here we are linking together the idea of the solution to the system itself
  • Program: The actual code we write.
  • Machine: The hardware, OS, or runtime environment that runs the program.

At first glance, this might sound overly formal. But for a project like GRIOT, this structure is exactly what I need.

Why? Because systems without clear boundaries collapse under the weight of abstraction. And GRIOT, by design, is deeply abstract — part memory-keeper, part voice journal, part emotional mirror.

WRSPM helps anchor that vision in something real.

In Kurt Anderson’s course, WRSPM is introduced during the Requirements phase of the SDLC — because the first three layers (World, Requirements, Specifications) are all about defining the system before writing a single line of code. They form the full picture of what the system must be and do.

So even though the SDLC separates things into steps like Requirements, Design, Implementation, Testing, and Maintenance, WRSPM gives us a lens to go deeper during each phase — especially at the beginning.

Here’s how they interrelate:

SDLC PhaseWRSPM Layers InvolvedFocus
RequirementsWorld → Requirements → SpecificationsUnderstand the problem, define what’s needed, and shape a vision
DesignSpecifications → ProgramPlan architecture and flows to match the specs
ImplementationProgramWrite the code
TestingProgram ↔ SpecificationsEnsure the code matches the intended design
Deployment/MaintenanceProgram → MachineGet the system running in the right environment

This layered way of thinking changed how I approached GRIOT.

For me, WRSPM isn’t just about software modeling. It’s about intentionality.

In the same way a griot honors the memory of a people through structure — lineage, rhythm, voice, and recall — WRSPM lets me honor the vision of this project by organizing its layers with care.

GRIOT as system, tool, and heir

Before I write a single line of code, I need to answer a deeper question:
What exactly am I building?

GRIOT isn’t just an app. It’s a system, a tool, and in many ways, an heir—a continuation of the legacy of storytelling, memory-keeping, and reflection carried by West African griots for centuries.

As a System

GRIOT listens, stores, and reflects. It processes voice logs, syncs data with memory, and responds with structured insight. Under the hood, it’s a software system—made of modules, services, interfaces, and a machine context. Every decision I make in the codebase is filtered through this lens:
How does this serve the larger system of memory, voice, and presence?

But unlike most systems, GRIOT isn’t built for the crowd. It’s built for one:
a user who wants to grow, reflect, heal, or just be witnessed.

As a Tool

GRIOT is also a utility. It’s meant to be used. Daily. Quietly. Personally.

Like a journal, mirror, or compass, it’s there to assist—not distract. It’s not gamified. There are no push notifications begging for attention. Instead, GRIOT waits, listens, and responds when needed.

The goal isn’t engagement—it’s alignment.
Helping the user remember who they are, what they’ve survived, and what they value.

As an Heir

Most importantly, GRIOT is an heir to a lineage.

GRIOT draws direct inspiration from the griots of West Africa—oral historians, musicians, advisors, and keepers of memory. Traditionally, a griot wasn’t just a storyteller; they were the living memory of a people. They carried generations of knowledge, lineage, conflict, wisdom, and song—passed down not through hard drives, but heartbeats.

They didn’t just document the past.
They helped communities understand it.
And they spoke truth—even when it was difficult.

That spirit lives at the core of this system.

GRIOT is more than a catchy name. It’s also an acronym for the roles this system is designed to embody:

G.R.I.O.T. =
Guardian of Reflection, Insight, Origin, and Truth

Like its namesake, this app isn’t just collecting data.
It’s listening.
It’s holding memory.
And it’s offering back meaning—through reflection, context, and voice.

GRIOT is an heir to that tradition—reimagined through code.

By approaching GRIOT as a system, a tool, and an heir, I stay rooted in all three layers:

  • The technical, where I build and test modules
  • The personal, where I interact with the system to grow
  • And the ancestral, where I honor a deeper calling in my work

That’s the foundation.

Defining the ‘World’ and ‘Requirements’ for GRIOT

To build any system well, you have to understand the world it lives in — not just technically, but humanly.

Below, I outline the first two foundational frames of WRSPM for GRIOT:

  • World Assumptions (W): What must be true — or generally expected — about the environment, user, and device.
  • GRIOT-Inspired Requirements (R): What the system must do, grounded in purpose, behavior, and user needs.

World Assumptions (W)

What GRIOT assumes about the user, device, and environment in order to function properly:

  1. The user has access to a device with a functional microphone.
    GRIOT depends on the presence of a mic-enabled device (smartphone, tablet, etc.) for voice input.
  2. The device is located in a personal or semi-private environment where the user feels safe speaking aloud.
    For honest reflection and voice journaling, GRIOT assumes a space where the user is comfortable using their voice.
  3. The user is able to speak fluently in at least one supported language: English, French, or Spanish.
    GRIOT assumes verbal fluency in one of these languages for accurate transcription and understanding.
  4. Background noise levels may vary.
    GRIOT assumes the physical environment may not always be quiet, and this can affect recognition accuracy.
  5. An internet connection is usually available but not guaranteed.
    While GRIOT may offer limited offline behavior, it assumes the internet is generally accessible for responses and syncing.
  6. Users are familiar with speaking to virtual assistants or are willing to learn.
    GRIOT assumes some cultural or technological exposure to voice-based interaction, even if minimal.
  7. The user is the intended speaker unless otherwise configured.
    GRIOT assumes it is listening to the same user each time unless voice identification is implemented in the future (it will, but baby steps).
  8. The user’s attention and tone can vary depending on emotional state.
    GRIOT assumes shifts in voice tone, pace, and emotional intensity can carry meaning, though it may not always be clear.
  9. The system may be running in the background during other activities.
    GRIOT assumes it may be ambiently active without being the primary focus (e.g. journaling while walking, cooking, or resting).
  10. The user will return to the system over time. 🆕
    GRIOT assumes ongoing, repeated engagement — not just one-off use — allowing memory and reflection to compound.
  11. The user’s context and identity may evolve. 🆕
    GRIOT assumes that what it knows about the user (preferences, tone, emotional baseline) will change and must be updated over time.
  12. The user has granted permission to access fitness data from their device.
    GRIOT assumes users have a connected health or fitness tracking device (e.g., Apple Watch, WearOS watch) and allow access to basic workout or activity data.
  13. The user’s fitness data is relevant to their emotional and personal growth journey.
    GRIOT assumes users see value in connecting physical health insights to emotional, mental, or spiritual reflection.

Traditional griot-Inspired Requirements (R)

What GRIOT must offer, enable, or respond to — grounded in function and care:

1. Memory Keeper

  • The user shall be able to record verbal reflections, which are securely stored and retrievable over time.
  • The system shall ensure voice logs are timestamped and optionally tagged with emotions or themes.
  • The system shall summarize past logs to help users track emotional, mental, and spiritual growth.

2. Storyteller

  • The system shall be able to retell user-provided moments in story form upon request, optionally highlighting lessons, emotions, or personal victories.
  • The user shall be able to ask for a daily or weekly life story reflection inspired by recent logs.

3. Praise Singer

  • The system shall offer positive reinforcement or affirming language when the user reflects on accomplishments, progress, or moments of courage.
  • The user shall receive personalized praise in moments of consistency, self-awareness, or resilience.

4. Advisor to the Self

  • The system shall use user context (emotion, reflection patterns, prior entries) to offer gentle, non-intrusive suggestions for personal growth, wellness, or decision-making.
  • The user shall be able to ask GRIOT for guidance and receive GPT-powered reflections, tuned with an emotionally supportive tone.
  • The system shall use lightweight context memory to personalize its advice and tone based on the user’s evolving emotional patterns and preferences.

5. Oral Historian

  • The system shall optionally allow the user to store family stories, ancestral knowledge, or cultural wisdom as audio logs.
  • These stories shall be searchable, organized, and optionally shared with trusted contacts (future feature).

6. Musician & Atmosphere Weaver

  • The system shall offer ambient background soundscapes or music (e.g., kora, balafon, rain, wind) during reflection or meditation mode.
  • The user shall be able to toggle ambient sound to create a sacred or peaceful reflection space.

7. Mediator & Conflict Guide

  • The user shall be able to enter a conflict reflection mode, where GRIOT prompts them to explore emotions, needs, and possible resolutions.
  • The system shall offer non-judgmental space and insights to help the user emotionally process interpersonal situations.

8. Teacher & Guide

  • The user shall receive guided reflection prompts, journal themes, or affirmations based on past behavior or voice logs.
  • GRIOT shall surface curated wisdom or quotes from African philosophy, oral traditions, or user-submitted teachings.

9. Context-Aware Agent Behavior 🆕

  • The system shall store and retrieve user context (e.g., recent logs, preferences, recurring emotional patterns) to inform ongoing interactions.
  • The user shall be able to update or reset personal context and memory as needed.
  • The system shall maintain a lightweight memory layer that informs personalization without overstepping or misrepresenting the user.
  • The system shall gracefully degrade when context is missing (e.g., during first use or offline mode).

10. Fitness Mentor

  • The system shall be able to access basic fitness data (e.g., activity logs, step count, exercise sessions, heart rate trends) from supported platforms like Apple HealthKit or Google Fit.
  • The user shall receive reflective feedback or encouragement based on fitness consistency or patterns.
  • The system shall optionally highlight connections between physical activity and emotional well-being.
  • The user shall be able to request fitness summaries, nudges, or reminders in a reflective tone (not taskmaster-style).

Mapping Requirements to Specifications

Now we bridge the gap between high-level system requirements and concrete specifications. We will do this by translating each requirement into a technical expectations the system must meet.

R1. Memory Keeper → S1-S3

  • S1: The system shall support high-quality voice recording using the device’s microphone
  • S2: Each voice log shall be timestamped, securely stored, and retrievable via voice or touch UI.
  • S3: The system shall offer emotion tagging and thematic labeling via GPT-assisted analysis.
  • S4: A “memory summary” feature shall condense past reflections into key emotional patterns and themes for the user to revisit.

R2. Storyteller → S4-S6

  • S5: Upon user request, the system shall generate story-style narratives from selected voice logs.
  • S6: Stories shall emphasize emotional turning points, values, or life lessons
  • S7: Users can optionally ask for a daily, weekly, or milestone-based life reflection, auto-generated from recent logs.

R3. Praise Singer → S7-S9

  • S8: The system shall detect and celebrate consistent use or reflection milestones.
  • S9: Personalized praise shall reflect the user’s growth history, emotional resilience, and identity-based affirmations.
  • S10: Praise delivery shall match the user’s tone and attention span, and may include voice or text-based encouragement.

R4. Advisor to the Self → S10-S13

  • S11: The system shall use emotion detection and past reflection patterns to gently suggest growth prompts or questions.
  • S12: When the user asks for advice, GRIOT shall generate GPT-powered responses based on current and past context.
  • S13: A lightweight context layer (identity, tone, preferences) shall personalize all advice while avoiding intrusive behavior.
  • S14: If context is unavailable (e.g., new user or offline), the system shall respond gracefully with generic reflection prompts.

R5. Oral Historian → S14-S16

  • S15: The user can tag certain voice logs as ancestral, cultural, or family-based oral histories.
  • S16: These logs shall be indexed with metadata and optionally organized into themed collections.
  • S17: Sharing functionality (future feature, baby steps) shall be gated by permissions and community trust signals.

R6. Musician & Atmosphere Weaver → S17-S19

  • S18: The System shall provide option background audio during reflection: e.g., wind, water, balafon, lo-fi, and give user option to turn ambient sound on/off
  • S19: The system shall synchronize music volume and duration with the user’s reflection session.
  • S20: Custom sound themes may be downloadable based on user mood or preferred reflection state.

R7. Mediator & Conflict Guide → S20-S22

  • S21: The system shall provide a “conflict reflection” mode, with prompts to explore emotion, needs, and values.
  • S22: Conflict reflections shall be tagged and summarized for later review to aid in emotional tracking.
  • S23: GRIOT shall remain neutral and non-judgmental in tone when mediating or guiding such entries.

R8. Teacher & Guide → S23-S26

  • S24: Based on past entries, the system shall surface personalized reflection prompts or journaling themes.
  • S25: Daily/weekly affirmations shall be suggested based on emotional baseline.
  • S26: Curated wisdom (African philosophy, proverbs, user-submitted quotes) shall be delivered when the user seeks guidance or daily centering.

R9. Context-Aware Agent Behavior → S27-S31

  • S27: The system shall store user preferences, tone patterns, and emotional baselines to inform future interactions.
  • S28: All memory shall be editable and resettable by the user (data sovereignty).
  • S29: When insufficient context exists (e.g., first time use), GRIOT shall use default non-personalized responses.
  • S30: Memory shall update gradually over sessions, not based on a single input, ensuring an evolving mirror rather than a rigid model.
  • S31: Users shall receive periodic summaries of how their context is used and have the option to refine it.

R10. Fitness Mentor → S32-S36

  • S32: The system shall request and access fitness data via HealthKit or Google Fit with explicit permission .
  • S33: Users can ask GRIOT for fitness summaries, streaks, or health check-ins in reflective, gentle language.
  • S34: The system shall surface possible connections between physical activity and emotional reflections when appropriate (e.g., calmer tone after runs).
  • S35: Users can enable or disable fitness insight suggestions as part of their profile preferences.
  • S36: Activity-based praise or reflection nudges shall remain non-coercive, affirming the user’s autonomy and dignity.

How This Sets GRIOT Apart

GRIOT is not just another journaling app or voice assistant. It reimagines personal technology as an ambient AI companion, one that honors memory, identity, and emotional truth through voice. What makes GRIOT fundamentally different are the following pillars:


Voice as Sacred Interface

Where most journaling apps center around typing, GRIOT treats the spoken word as the most natural and emotionally rich form of self-expression. The system listens, remembers, and responds — like a wise elder or confidant — allowing users to reflect aloud, grieve, celebrate, or simply be.

  • Not just transcribed text. GRIOT understands tone, cadence, and emotional intensity.
  • Mic-first design. It’s built to work ambiently — during a walk, a quiet moment in bed, or a morning routine.

Memory as Living Reflection

GRIOT doesn’t just store logs — it weaves them into a personal story. With lightweight context memory, timestamped voice logs, emotional tagging, and weekly summaries, it helps users witness their own transformation over time.

  • It becomes a mirror for growth, gently surfacing patterns, shifts, and small victories.
  • Memory is contextual, not static — always evolving with the user’s current self.

African Philosophical Roots

GRIOT is deeply inspired by the oral traditions, ancestral respect, and holistic worldview of African cultures.

  • The Praise Singer offers affirmations drawn from West African oral praise practices.
  • The Oral Historian allows users to preserve family and cultural stories — honoring intergenerational wisdom.
  • Quotes, affirmations, and meditative prompts reflect Afrocentric thought, not just Western psychology.

This isn’t flavor text — it’s foundational to GRIOT’s identity.


Emotional Context as Core Data

Rather than treating emotion as a nice-to-have, GRIOT makes it central. It tunes every reflection, summary, or prompt based on the user’s emotional tone, history, and reflection patterns — and knows how to gracefully pull back when unsure.

  • GPT responses are softened, patient, and respectful — not transactional.
  • Context-awareness evolves slowly and protects user autonomy.

Multiplicity of Roles, One Trusted Presence

GRIOT plays many parts — but always stays grounded in the user’s journey:

  • Memory Keeper for voice journaling
  • Praise Singer for emotional encouragement
  • Advisor to the Self for reflection and self-direction
  • Oral Historian for family storytelling
  • Fitness Mentor for aligning body and mind
  • Mediator for processing conflict
  • Teacher for affirmations and ancestral wisdom

Each role is embodied through simple, voice-first interactions — no feature bloat, just purpose.


Built for Quiet Use, Not Social Performance

There are no streaks, likes, or follower counts. GRIOT is not performative. It’s private, sacred, and meant to be used in silence, solitude, or spiritual practice — a modern griot sitting quietly with you.


Fitness as Reflection, Not Discipline

Unlike apps that yell, “Go harder,” GRIOT might say:
“I noticed you walked a bit more this week. How did that feel in your body?”
It connects movement with meaning, offering encouragement without judgment.


Technically Lightweight, Emotionally Heavy

GRIOT runs on low-bandwidth voice recognition, local journaling support (when offline), and GPT-assisted insights — but it carries emotionally dense value. It doesn’t require a massive system to be a meaningful part of your day.

Conclusion

Most software is built to scale.

GRIOT is being built to remember.

To me WRSPM model isn’t just a tool, it’s a quiet act of resistance against the rush to ship and discard. It’s a way to honor each layer of a system before writing a single line of code.

This phase is about laying the foundation with care, so the rest of the build emerges from something rooted, not reactive. A tech artifact that grows with the user, not away from them.

Questions I’m Sitting With

  • What does it mean to build tech that remembers — not just responds?
  • Can software honor voice, lineage, and emotional truth without feeling extractive?
  • Have we rushed past the roots in our race to ship?
  • What changes when we let care lead the architecture?

I’ll keep sharing the process as I move through each stage of the SDLC with care.

Christian
Christian
Articles: 16