DEV Community: Rono

Blessed Be the Conversation That Sharpens My Machine

Rono — Sun, 21 Jun 2026 13:48:19 +0000

This is a follow-up to How I Designed Invariants for AI-Human Collaboration. If you haven't read that, the short version: I built three rules into a collaborative AI system that made it trustworthy. One of those rules was a boolean flag called isManuallyEdited. This post is about what happened next.

How isManuallyEdited Trains My Local AI Through Dialogue

It started as a simple boolean. A single field in a database. A marker that said: "A human touched this."

That flag is isManuallyEdited.

And it turned out to be the beginning of a feedback loop I hadn't fully planned.

The problem: an AI that didn't learn from its mistakes

When I first built my local AI system, I ran into a familiar frustration.

The AI would generate responses. I would correct them. The AI would make the same mistakes again.

There was no memory. No learning. No connection between the correction and the next generation.

The machine wasn't dumb because it lacked data. It was dumb because it lacked a mechanism to receive feedback.

The solution: treating isManuallyEdited as training signal

In the original system, isManuallyEdited protected human corrections from being overwritten. The flag flipped to true, and the AI couldn't touch that row again.

That was Invariant 2 from the last post: the override-is-sacred rule.

But I realised the flag was also sitting on a goldmine of signal I wasn't using.

Every isManuallyEdited = true record is a pair: what the AI produced, and what a human decided it should actually say. That's a labeled training example. And I had hundreds of them.

So I added one more step to the pipeline: store the edit, and queue it for retraining.

class AIGeneratedContent:
    content: str
    isManuallyEdited: bool = False
    originalContent: str
    editedContent: Optional[str] = None
    editHistory: List[Edit] = []

    def edit(self, new_content: str) -> None:
        self.isManuallyEdited = True
        self.editedContent = new_content
        self.editHistory.append(Edit(
            before=self.content,
            after=new_content,
            timestamp=datetime.now()
        ))
        self.queue_for_retraining()

The change was small. The effect was not.

The loop

AI generates output
        ↓
Human corrects it
        ↓
isManuallyEdited = True
        ↓
Edit stored as labeled pair (original → corrected)
        ↓
Model fine-tuned on accumulated edits
        ↓
AI generates better output

The human speaks through corrections. The model listens through retraining. Each edit becomes data. The loop runs continuously instead of in scheduled monthly batches.

What the loop produced

Over the months since I added the retraining pipeline, I tracked every edit.

Metric	Before	After
Outputs requiring manual correction	~40%	~12%
Accuracy in my specific domain	62%	89%
Retraining schedule	Manual, monthly	Automated, continuous

The model didn't just improve on average — it improved on the specific mistakes that actually mattered to my workflow. Because those were the mistakes I was correcting.

Generic fine-tuning on public datasets could not have done that. Only my own corrections, on my own data, in my own domain, could.

How to implement this in your own system

If you already have an isManuallyEdited flag (or similar provenance tracking), you're most of the way there.

Step 1: Flag every manual intervention

ALTER TABLE ai_outputs ADD COLUMN is_manually_edited BOOLEAN DEFAULT FALSE;
ALTER TABLE ai_outputs ADD COLUMN original_text TEXT;
ALTER TABLE ai_outputs ADD COLUMN edited_text TEXT;

Step 2: Store the full edit history

class EditHistory:
    edits: List[Dict] = []

    def record_edit(self, before: str, after: str, user_id: str):
        self.edits.append({
            "before": before,
            "after": after,
            "user": user_id,
            "timestamp": datetime.utcnow()
        })

Step 3: Build a retraining pipeline

def retrain_on_edits():
    edits = get_all_manually_edited_outputs()
    training_data = [
        {
            "input": edit.original_text,
            "expected_output": edit.edited_text
        }
        for edit in edits
    ]
    model.fine_tune(training_data)

Step 4: Measure the sharpening

Track:

Edit rate over time (should decrease)
User correction effort (should decrease)
Accuracy benchmarks against your domain (should increase)

The metrics tell you whether the loop is working. If edit rate stops falling, something in the pipeline is broken — or the model has hit the ceiling of what your current corrections can teach it.

What this is not

I want to be honest about scope, the same way I was in the last post.

This is not RLHF. I'm not training a reward model or doing reinforcement learning. I'm doing supervised fine-tuning on correction pairs. It's simpler, more brittle, and appropriate for my scale.

This does not replace prompt engineering. Some mistakes are better fixed by improving the prompt than by retraining. I do both. When I see a pattern in the corrections, I often fix the prompt first and retrain second.

This works at small scale. Hundreds of labeled corrections, a local model, a single domain. At production scale with millions of users, you'd need more infrastructure and more careful data curation. But the principle holds.

The AI is not conscious of the feedback. It doesn't "know" it's being corrected. The learning happens through gradient updates, not understanding. I mention this because it's easy to slip into anthropomorphizing the loop.

The test of time

The isManuallyEdited flag was first written on April 27, 2026.

It still hasn't changed.

What changed is what I do with it. The flag was always there. The retraining pipeline was the thing I added later, once I realized I was sitting on training data I wasn't using.

If you already track manual edits in your system, you may be in the same position. The signal is there. The question is whether you're listening to it.

Kiprono Ngetich builds AI-assisted collaboration tools. He thinks too much about data provenance and feedback loops.

The Organization Is a Conversation

Rono — Tue, 16 Jun 2026 04:17:00 +0000

Two invariants that turned our internal tool from “another status sheet” into something people called magic

The first time someone at work called our internal tool “magic”, I felt both proud and slightly uneasy.

They weren’t looking at code. They weren’t thinking about architecture. They just noticed that status reports stayed accurate, action items didn’t disappear, and the system somehow knew when a human had made a deliberate decision and refused to overwrite it.

It felt like magic.

It wasn’t.

It was the result of a simple but uncomfortable idea:

The organization is not a database, an org chart, or a set of tickets.
The organization is a conversation.

Everything else reports, roadmaps, backlogs is just a projection of that living conversation.

Most systems get this backwards. They treat the projections as primary and force humans to constantly update them.

We did the opposite.

Why Most Systems Fail

Walk into any organization and you’ll see the same pattern.

A project manager spends hours chasing updates. People copy the same information into spreadsheets, then status reports, then slide decks. Someone manually adjusts a deadline and later discovers the system quietly reverted it.

This happens because we treat communication as noise and structure as truth.

In reality, it’s the other way around.

Communication is where truth first appears:
Slack messages, voice notes, meeting fragments, quick approvals that’s the real system.

Everything structured is just a shadow.

When tools ignore this, they create friction and slowly erode trust.

A typical “fact lifecycle” looks like this:

Someone says something in a conversation
Someone copies it into a spreadsheet
Someone else moves it into a status report
An AI summarizes it again
The original context disappears

By the end, you have multiple “truths” none of them traceable.

That is not a collaboration problem.

It is an architecture problem.

What We Built

Daraja Workspace started as an internal fix for a simple problem:

weekly status reports were killing us.

Teams wrote rich weekly updates. Someone retyped them into sheets. Sheets went stale. People chased updates. Thursday afternoons became chaos.

So we built a system that listens to those conversations and turns them into live operational memory.

The flow looks like this:

Team conversations (Slack, email, WhatsApp, voice notes)
                ↓
            AI listens
                ↓
Extract structure: clients, tasks, owners, deadlines
                ↓
   Live collaborative status sheet
                ↓
   Humans correct mistakes
                ↓
System learns: “this was manually edited”
                ↓
        Corrections persist

No forms. No duplicate entry. No “please update your status” messages.

And importantly:

When someone asks, “Where did this deadline come from?”
the system can trace it back to the original conversation.

The conversation is not lost. It is the system.

The Problem We Kept Running Into

Early versions failed in a very specific way.

The AI would generate something useful. A human would correct it. Then the AI would regenerate later and overwrite the correction.

Trust collapsed immediately.

People stopped fixing errors. They just lived with them.

The issue wasn’t model quality.

It was architecture.

The system treated every run as stateless. It didn’t understand that a human correction is a stronger signal than a fresh prediction.

So we introduced two invariants.

Invariant 1: Generate Once

The AI is allowed to generate a structured view of a conversation only once.

After that, it stops regenerating and only observes.

In practice:

First time a week is opened → AI generates the status sheet
Subsequent visits → system returns stored version
No regeneration
No silent overwrites

This eliminated the worst failure mode immediately.

No more “I fixed this yesterday, why is it wrong again?”

It also had a side effect:

We went from O(n views) AI cost → O(weeks of data)

Invariant 2: Human Override Is Final

When a human edits a field, that decision becomes authoritative.

We store a simple flag:

isManuallyEdited: true

If false, AI can suggest improvements.

If true, AI must never overwrite it.

Example:

{
  "project": "Campaign Launch",
  "deadline": "2026-10-16",
  "isManuallyEdited": false
}

After human correction:

{
  "project": "Campaign Launch",
  "deadline": "2026-10-14",
  "isManuallyEdited": true,
  "originalAiDeadline": "2026-10-16"
}

The system doesn’t lose history it preserves both versions.

But authority is no longer ambiguous.

What This Unlocked

Once these two rules were in place, everything changed.

No more chasing updates
No duplicate data entry
No stale status sheets
No Thursday panic
No silent overwrites

The status report effectively became self-writing.

And more importantly:

People started trusting it enough to actually correct it.

That trust created better data, which improved extraction quality, which improved trust again.

A feedback loop formed.

The Numbers

After several months internally:

11 weeks of history
500+ extracted tasks
3,000+ messages processed

And none of it was manually entered.

The team just worked. The system listened.

Why This Isn’t a Chatbot

People hear “AI + communication” and assume chatbot.

This is not that.

A chatbot is an actor in a conversation.

This is something else entirely.

Daraja Workspace is an observer.

It does not interrupt.

It does not ask questions.

It does not participate.

It simply watches human communication and maintains operational memory from it.

The best workplace AI is the one you never talk to directly.

You don’t chat with it.

You just keep working.

On “Magic”

When people call it magic, what they’re really reacting to is this:

Finally, a system that doesn’t fight how work actually happens.

Most tools force structure onto humans.

This one extracts structure from human behavior.

That difference changes everything.

Where This Pattern Applies

This is not a narrow idea.

It shows up everywhere:

Agencies → client updates in Slack and email
Consulting → risks surfaced in meetings
Software teams → bugs in chats and standups
Support → issues in calls and WhatsApp
Startups → everything too fast for forms

In every case:

Communication is the system of record.
Everything else is a projection.

Closing

In the beginning was the word.

The word was spoken everywhere chats, meetings, messages, calls.

And it already contained everything the organization needed to know.

We were just not listening.

The future of workplace software is not better forms.

It is systems that turn communication into living operational memory.

The organization speaks.
The system listens.
The status report writes itself.

In the Beginning Was the Word

Rono — Wed, 10 Jun 2026 20:36:41 +0000

Why your organization's source of truth isn't your database it's your conversation

Every organization already contains its operational state.

It is not in the CRM. It is not in the project tracker. It is not in the weekly status report that took four hours to assemble and was obsolete the moment it landed in inboxes.

The operational state lives in conversations.

Client updates happen in Slack threads. Deadlines shift in email chains. Approvals are granted in WhatsApp groups. Ownership transfers in five-minute Zoom calls that no one recorded. Risks are surfaced in the corridor, the team lunch, the late-night message that begins, "So, here's the thing..."

Every piece of information that matters every decision, every commitment, every change is communicated before it is recorded. And often, it is communicated and never recorded at all.

This is not a failure of discipline. It is a mismatch of architecture.

The Duplication Machine

Watch how information moves through a typical organization.

A project manager writes a weekly summary. In that message — unstructured, natural, human lies the complete state of the project: which clients are happy, which deliverables are delayed, who is responsible for what, what needs approval by Friday.

Then the duplication begins.

The same information is copied into a spreadsheet. Then into a status report. Then into a CRM field. Then into a project tracker. Then into a slide deck for leadership.

Communication → Spreadsheet → CRM → Status Report → Project Tracker → Slide Deck

Each copy introduces the possibility of error. Each copy falls out of sync. Each copy requires maintenance. And every person involved knows quietly, resignedly that the canonical source of truth is actually none of these.

The canonical source of truth is the conversation. But the conversation is treated as transient. It scrolls away. It is forgotten. It leaves behind a trail of duplicate, contradictory, stale artifacts.

Organizations do not have a data problem. They have a translation problem. They convert human communication into structured state manually, repeatedly, imperfectly and then pretend the structured state is the real thing.

An Alternative Architecture

What if the workflow were reversed?

What if communication was not the input to a manual data entry process, but the canonical source and everything else emerged from it?

Human Communication
        ↓
   AI Synthesis
        ↓
Structured Operational State
        ↓
Reports, Dashboards, CRMs, Project Systems

In this architecture, structured systems are not maintained by humans. They are derived from communication. The status report does not need to be written. It is extracted. The CRM does not need to be updated. It is synchronized. The project tracker does not need to be reconciled. It is generated.

This is not magic. It is a different assumption about where truth lives.

The traditional assumption: Truth lives in the database. Humans update the database. Communication is a secondary channel for coordination.

The alternative assumption: Truth lives in communication. The database listens. Structured systems are downstream projections.

A Case Study: Daraja Workspace

I built a system based on this assumption.

The problem was familiar. Teams produced weekly summaries rich with project intelligence client names, deadlines, activities, owners, blockers. Then they manually transcribed that intelligence into status sheets that were outdated by the time they were shared.

The solution was not a better template or stricter deadlines. It was a different architecture.

Step one: Treat communication as the source. Every weekly summary was stored as an immutable record. No structure imposed at write time. Just the raw, natural message.

Step two: Extract structure on read. An AI pipeline processed each message and synthesized the latent operational state: clients, brands, projects, activities, people in charge, timelines, approvals.

Step three: Make structure collaborative. The AI output became the initial state of a living status sheet — editable, real-time, shared. Humans corrected what the AI got wrong. The system remembered the difference.

Step four: Never overwrite human judgment. Every piece of state carried a provenance flag: isManuallyEdited. AI-generated values were provisional. Human-corrected values were authoritative. The system learned the distinction.

What emerged was not a chatbot. It was a continuous maintainer of organizational state. The AI did not talk to humans. It listened to them. It synthesized their communication into a living operational memory.

The Entities That Emerged

From the raw stream of conversation, operational entities emerged naturally:

Clients — named and referenced repeatedly
Brands — attached to specific deliverables
Projects — clusters of activities with shared goals
Activities — discrete work items with owners and timelines
Owners — people identified as responsible
Timelines — deadlines and delivery dates
Approvals — explicit or implicit sign-offs

The system did not require these entities to be predefined. They emerged from the language teams already used. The ontology was not imposed. It was discovered.

This is the opposite of traditional data modeling. Traditional modeling says: Define your schema. Train your users. Enforce compliance.

This approach says: Listen to how people actually communicate. Extract the schema from their language. Adapt as they adapt.

The Invariants

Extracting structure from conversation is not enough. The structure must be trustworthy.

Here are four invariants that make AI-human collaboration work in operational environments:

Invariant one: Traceability

Every piece of structured state must be traceable to the communication that produced it. If a deadline appears in the status sheet, the original message containing that deadline must be retrievable. No synthetic state without evidence.

Invariant two: Human accountability

The AI may synthesize information, but it cannot own accountability. A human must be responsible for every important decision. The AI proposes; the human disposes. The system remembers who decided what.

Invariant three: Human authority

When a human corrects an AI extraction, the correction is immediately authoritative. The AI does not overwrite it. Not tomorrow. Not after retraining. Never. This is not about model quality. It is about operational trust.

Invariant four: Bidirectional consistency

Structured state must remain consistent regardless of whether updates originate from humans or AI. If a human updates a status sheet, the downstream reports reflect it. If the AI discovers new information in a conversation, the status sheet updates. No forks. No reconciliations. One truth.

These invariants shift the relationship between humans and AI. The AI is not a chatbot — a transient conversational partner. It is a continuous listener. It does not wait to be asked. It pays attention. It synthesizes. It maintains.

Where This Pattern Applies

This is not a narrow solution for project status reports. The pattern generalizes.

Agencies: Client updates live in email and Slack. Campaign status, creative approvals, budget changes — all communicated before they are recorded. A listening system could maintain the agency's operational state continuously, eliminating the weekly status panic.

Consulting firms: Engagement risks are surfaced in partner meetings and team chats. Issues are raised before they are logged. A system that listens could transform fragmented communication into a real-time risk register.

Software teams: Bug reports, feature requests, deployment timelines — all discussed in GitHub issues, Slack threads, daily standups. A listening system could synthesize these conversations into a living project dashboard that never requires manual updates.

Customer support teams: Customer issues are raised in calls, emails, WhatsApp groups. A listening system could extract tickets, track resolutions, and maintain customer state without agents duplicating work across multiple tools.

Startups: Everything moves too fast for disciplined data entry. Communication is the only reliable record. A listening system could become the startup's memory — capturing decisions, surfacing action items, maintaining context as the team scales.

In every case, the pattern is the same: treat communication as the source, extract structure on read, maintain provenance, preserve human authority.

Why This Isn't Just Another Chatbot

There is a common misunderstanding. When people hear "AI + communication," they think of chatbots. Conversational interfaces. Something that talks back.

That is not what this is.

A chatbot is a participant in a conversation. It responds. It answers questions. It generates text.

A listening system is an observer. It does not interrupt. It does not ask for clarification. It pays attention to the conversation humans are already having with each other. It extracts, synthesizes, and maintains — without adding to the noise.

This distinction matters because the goal is not to replace human communication with AI. The goal is to make human communication the canonical source of truth, with AI as the continuous transformer.

The best workplace AI is the one you never talk to directly. It just works. It keeps the organization's memory alive. It makes the status report write itself. It surfaces the risk before it becomes a crisis.

You do not chat with it. You just keep working. It listens.

The Future Workplace

For decades, workplace software has been built on a single assumption:

The organization updates the database.

Forms. Fields. Workflows. Approvals. Compliance. All designed to move information from human communication into structured systems. The friction is immense. The data is always stale. The duplication is endless.

What if the assumption were different?

What if the organization simply spoke — and the database listened?

Not voice commands. Not chatbots. Not conversational UI. Something deeper. A system that sits in the background of every conversation, extracting the operational state that already exists, maintaining it continuously, projecting it into whatever structured views the organization needs.

The status report writes itself. The CRM updates from the email thread. The project tracker reflects the Slack conversation. The risk register surfaces from the partner meeting.

No forms. No double-entry. No reconciliation.

Just communication. And a system that pays attention.

Closing

In the beginning was the word.

The word was spoken in a thousand channels: email, chat, call, message, meeting, memo.

And the word contained everything the organization needed to know.

We just were not listening.

The future of enterprise software is not better forms or stricter compliance. It is systems that continuously transform human communication into living operational memory.

The organization speaks. The database listens.

The status report writes itself.

This essay is based on work from Daraja Workspace, an Internal tool I built as an open experimental project which is currently used as the primary source of communication at my current workplace, exploring AI-assisted collaboration. The code is not yet public, but the ideas are.

Tags: #ai #softwareengineering #productivity #startup #projectmanagement #architecture

Kiprono Ngetich builds systems that listen. He writes about AI, collaboration, and the future of workplace software.

How I Designed Invariants for AI-Human Collaboration

Rono — Sat, 06 Jun 2026 02:53:38 +0000

The morning it clicked

April 27, 2026. 8:30 AM. I opened my laptop with a specific problem: the AI kept overwriting human corrections, and my team was starting to lose trust in the tool we were building.

Not because the AI was bad. Because the architecture was wrong.

We had built a beautiful real-time collaborative status sheet. AI read weekly summaries and generated project rows. Multiple people could edit simultaneously. WebSockets broadcast changes instantly. It felt like magic.

But every time the AI ran again, it would regenerate the sheet from scratch. Human corrections? Gone. Manual overrides? Vanished. The project manager who spent ten minutes fixing deadlines and adding comments would come back the next day to find the AI's original, wrong version staring back at her.

She stopped correcting. She stopped trusting. She stopped using the tool.

That morning, I wrote three invariants into the code. They took 42 minutes to implement. They have not changed in the months since. And they turned a chaotic prototype into a system people actually rely on.

This article is about those invariants: what they are, why they matter, and how you can apply the same thinking to your own AI-human collaboration systems.

The problem with AI-generated content in collaborative tools

Before we get to the invariants, let me describe the problem precisely.

You have an AI that reads unstructured text (weekly summaries, Daraja Workspace messages, email threads) and extracts structured data (tasks, deadlines, owners, status). You present this data in a collaborative interface where humans can view, edit, and enrich it.

This creates a tension:

The AI is good at	Humans are good at
Processing large volumes of text quickly	Understanding nuance and context
Extracting obvious structure	Catching subtle errors
Working 24/7 with no fatigue	Making judgment calls
Being consistent	Being correct when it matters

Neither can fully replace the other. The AI will make mistakes. The humans will not have time to fix everything. The system needs both.

But traditional architectures treat AI output as ephemeral and human input as temporary. The AI regenerates on every view. The human corrections are stored in the UI state but not protected from future AI runs. The result is a system where trust never builds because the machine keeps forgetting what it was taught.

Here is what I learned: the problem is not the AI. The problem is the absence of invariants.

Invariants are rules that the system guarantees will always be true. They are not features. They are not configurable. They are the bedrock. When you design invariants for AI-human collaboration, you are answering one question: in any conflict between machine output and human judgment, who wins?

My answer:

The human wins. Always. Immediately. Permanently.

That answer became three lines in the code.

Invariant 1: The POST-once rule

The code

Future<void> _loadExistingStatus() async {
  setState(() => _isLoading = true);

  try {
    final response = await http.get(
      Uri.parse('https://api.rucks.co.ke/unfo/'),
    );

    if (response.statusCode == 200) {
      final List<dynamic> data = jsonDecode(response.body);
      final existingStatus = data.firstWhere(
        (item) => item['username'] == _roomName,
        orElse: () => null,
      );

      if (existingStatus != null && existingStatus['likes'] != null) {
        final savedData = jsonDecode(existingStatus['likes']);
        if (savedData['rows'] != null) {
          _rows = (savedData['rows'] as List)
              .map((row) => StatusRow.fromJson(row))
              .toList();
          _foundOnServer = true; // ✅ Mark as already on server — no POST needed
        }
      }
    }
  } catch (e) {
    // Error handling omitted for clarity
  }

  // Only generate (and POST) if nothing came back from the server
  if (_rows.isEmpty && !_foundOnServer) {
    await _generateNewStatus();
  }

  setState(() => _isLoading = false);
}

What it does

The system performs a GET lookup before ever invoking the AI. Generation — and the subsequent POST to persist results — occurs only when the lookup returns no existing data for the current week.

Why it matters

Most systems treat AI as an on-demand service. Every user, every refresh, every navigation triggers a new call to the model. This is fine for chatbots and search. It is disastrous for collaborative documents.

Here is what happens without this invariant:

User A opens the week sheet → AI generates → POST saved
User B opens the same week sheet → AI generates again → POST overwrites
User A makes corrections → saves locally
User C opens the sheet → AI generates again → User A's corrections are gone

The sheet becomes a game of last-write-wins between the AI and every human who opens it. The AI, being faster and more frequent, usually wins.

The POST-once rule changes everything:

Without the rule	With the rule
AI runs on every view	AI runs once per week
Storage scales with views	Storage scales with weeks
Human corrections are fragile	Human corrections are permanent
No auditable baseline	First AI output is frozen baseline

The deeper insight

The _foundOnServer flag is the key. The system is not just checking if data exists — it is checking if data exists for this specific room name. The room name encodes the week number (week42_status). This means the invariant is scoped to the domain entity, not to the user session.

This is the difference between streaming intelligence (ephemeral, unrepeatable, distrustful) and settled intelligence (auditable, comparable, learnable). The first AI output becomes the fixed point against which all human corrections are measured.

What broke without it

Before this invariant, we had a week where the AI ran 47 times for the same status sheet. Forty-seven. Different users, different times of day, different devices. Each run overwrote the previous state. The sheet was never stable. Users reported that their corrections "disappeared" but could never reproduce the bug because the bug was the architecture itself.

The POST-once rule reduced API calls by 98% and eliminated the disappearing-corrections bug entirely.

Invariant 2: The override-is-sacred rule

The code

class StatusRow {
  final String client;
  final String brand;
  final String project;
  final String team;
  final String activities;
  final String pic;
  final String creative;
  final String timelines;
  final String comments;
  final bool isManuallyEdited;  // ← THE INVARIANT LIVES HERE

  StatusRow({
    required this.client,
    required this.brand,
    required this.project,
    required this.team,
    required this.activities,
    required this.pic,
    required this.creative,
    required this.timelines,
    required this.comments,
    this.isManuallyEdited = false,  // Default: AI-generated
  });

  StatusRow copyWith({
    // ... other fields
    bool? isManuallyEdited,
  }) {
    return StatusRow(
      // ... other fields
      isManuallyEdited: isManuallyEdited ?? this.isManuallyEdited,
    );
  }
}

And the edit handler:

void _editCell(int rowIndex, String column, String currentValue) {
  // ... dialog shown, user edits, newValue received

  // When saving the edit, we mark the row as manually edited
  final updatedRow = _rows[rowIndex].copyWith(
    [column]: newValue,
    isManuallyEdited: true,  // ← FLIP THE FLAG
  );

  setState(() {
    _rows[rowIndex] = updatedRow;
  });

  // Broadcast to other users
  _sendCellEdit(rowIndex, column, currentValue, newValue);
}

What it does

Every StatusRow carries a boolean flag: isManuallyEdited. It starts false for AI-generated rows. The first time a human edits any field in that row, the flag flips to true and never flips back.

The system preserves the original AI values in an audit trail (not shown in the simplified code), but the main view shows only the human-corrected version.

Why it matters

In most AI systems, human feedback is treated as a training signal — something that eventually improves the model after retraining, fine-tuning, or prompt adjustment. The latency between correction and effect can be hours, days, or weeks.

In operational environments, that latency is unacceptable. The human correction must be immediately authoritative. Not "the model will learn from this." Not "we'll update the prompt next sprint." Right now.

The isManuallyEdited flag enforces this at the storage layer, not just the application layer. Even if the AI reruns (which it won't, thanks to Invariant 1), it cannot overwrite a field where isManuallyEdited is true.

The trust multiplier

This invariant creates psychological safety. The AI is allowed to be wrong. No one is blamed for a bad extraction. The system simply accepts the correction and moves on.

I watched this happen in real time. A project manager corrected the same deadline field seventeen times over two months because the AI kept extracting the wrong date from the weekly summaries. (The summaries said "Friday" but the actual deadline was "Wednesday" due to a client change that was never updated in the summaries.)

Without the flag, she would have corrected it seventeen times and been frustrated seventeen times. With the flag, she corrected it once and never saw the wrong date again. The AI did not get smarter — the system simply stopped showing its mistake.

The audit trail pattern

The full implementation preserves the original AI values. The code snippet above does not show this for brevity, but here is the pattern:

class StatusRow {
  // Current values (human-corrected if applicable)
  final String client;
  final String brand;
  // ... other fields

  // Provenance
  final bool isManuallyEdited;
  final StatusRow? originalAiValues;  // Preserved on first edit

  // When a human edits:
  StatusRow humanEdit(String field, String newValue) {
    return StatusRow(
      // ... copy all fields, updating the edited one
      isManuallyEdited: true,
      originalAiValues: this.originalAiValues ?? this,  // Store original on first edit
    );
  }
}

This means you can always answer the question: "What did the AI originally think?" The answer is never lost. It is just demoted from the main view.

Invariant 3: The ephemeral presence boundary

The code

class _RealTimeStatusSheetPageState extends State<RealTimeStatusSheetPage> {
  // Track users in the room — stored in memory only, NEVER persisted
  final Set<String> _activeUsers = {};

  void _handleWebSocketMessage(dynamic message) {
    // ...
    if (messageText.contains('USER_JOINED')) {
      String username = extractUsername(messageText);
      if (username.isNotEmpty && username != widget.mUsername) {
        setState(() => _activeUsers.add(username));
      }
    }
    else if (messageText.contains('USER_LEFT')) {
      String username = extractUsername(messageText);
      if (username.isNotEmpty) {
        setState(() => _activeUsers.remove(username));
      }
    }
  }

  @override
  void dispose() {
    _sendUserLeaveMessage();  // Announce departure
    _channel.sink.close();
    super.dispose();
  }
}

What it does

User presence — who is looking at the status sheet right now — is stored exclusively in client-side memory. It is sent via WebSocket messages but never written to the database. When a user disconnects, they disappear from _activeUsers. When they reconnect, they re-announce themselves and reappear.

Why it matters

Ontologies and data models have a tendency to capture everything, including ephemeral state. This creates two problems:

Storage grows with activity, not with domain complexity. If you persist presence, you generate a record every time someone opens a sheet and every time they close it. For a team of 50 people working 5 days a week, that is 500 presence events per week — all of which are useless the moment they are written.
Queries become cluttered with irrelevant state. If you store presence in the same table as settled facts (like StatusRow values), every query has to filter out "is this person still online?" nonsense.

The invariant is simple: *if the information becomes false the moment you look away, do not write it to disk. *

What belongs in the database vs. what belongs in memory

Information	Storage location	Why
Status row values (client, project, deadlines)	Database	Settled truth, persists across sessions
Who created a row	Database	Historical record, audit requirement
When a row was last edited	Database	Track freshness, conflict resolution
Who is looking at the sheet right now	Memory only	Ephemeral, changes by the second
Who edited which cell and when	Database	Audit trail, compliance
Cursor positions	Memory only	Transient, session-specific

The reconnection pattern

Because presence is not persisted, the system must handle reconnections gracefully. The pattern is simple:

void _connectWebSocket() {
  _channel = WebSocketChannel.connect(Uri.parse(wsUrl));

  _channel.stream.listen(
    (message) => _handleMessage(message),
    onDone: () {
      // Connection lost
      setState(() => _activeUsers.clear());  // Clear presence
      _reconnect();  // Try to reconnect after delay
    },
  );

  // After reconnection, re-announce presence
  _sendUserJoinMessage();
}

When the WebSocket reconnects (after network blip, laptop sleep, or server restart), the client re-announces its presence. The server does not remember who was online before — it does not need to. The current set of connected clients self-assembles from scratch.

This is simpler, more reliable, and infinitely easier to debug than a persisted presence system with heartbeat timeouts and stale-cleanup jobs.

How the invariants work together

Alone, each invariant is useful. Together, they form a coherent system.

Invariant	Problem it solves	What it enables
POST-once	AI overwrites human work	Stable baseline, auditable first draft
Override-is-sacred	Human corrections are temporary	Trust, psychological safety, immediate authority
Ephemeral presence	Storage bloat, stale state	Real-time awareness without persistence complexity

Here is how they compose in a real scenario:

Monday, 9:00 AM: First user opens Week 42 sheet. POST-once rule triggers AI generation. Sheet saved to database. isManuallyEdited = false on all rows.
Monday, 2:00 PM: Project manager opens sheet. Sees wrong deadline. Edits cell. Override-is-sacred rule flips isManuallyEdited = true for that row. Edit broadcasts to all connected users via WebSocket.
Tuesday, 10:00 AM: Another user opens sheet. POST-once rule prevents regeneration. Override-is-sacred rule ensures they see the corrected deadline, not the AI's original. Ephemeral presence adds them to _activeUsers (memory only).
Tuesday, 3:00 PM: Network blip. All users disconnect. Ephemeral presence clears _activeUsers. No data lost because presence was never the source of truth.
Wednesday, 9:00 AM: Users reconnect. Ephemeral presence re-announces them. The corrected deadline is still there because it was written to the database under Invariant 2.

The invariants create a system where the AI is useful but not dominant, human judgment is respected but not overburdened, and real-time awareness is present but not over-engineered.

What these invariants are NOT

Let me be clear about what I am not claiming.

This is not CRDT or OT. I am not solving concurrent editing conflicts. If two users edit the same cell simultaneously, last-write-wins. For our use case (project status sheets), this is acceptable. For a Google Docs clone, it is not.
This is not a general AI training loop. The isManuallyEdited flag is not yet fed back into the model. The AI does not learn from corrections. That is the next phase. Right now, the flag only protects human edits from being overwritten.
This is not production-scale presence. The ephemeral presence system works for dozens of concurrent users. For thousands, you would need a more sophisticated approach (Redis, Ably, Pusher). Our scale is smaller, so the simple solution wins.
This is not a replacement for proper auditing. The audit trail preserves original AI values, but there is no per-cell timestamp or username tracking in the simplified code shown here. The production version has those.

I am sharing what worked for us. Your mileage may vary. The principles generalize; the specific implementations will need adaptation to your stack and scale.

How to apply these invariants to your own systems

You do not need to copy the code. You need to copy the thinking.

For the POST-once rule

Ask yourself: what operation am I performing repeatedly that should only happen once per domain entity?

Common candidates:

AI generation (obviously)
Data enrichment from external APIs
Summarization or aggregation
Notification sending ("first time someone views X, send an alert")
Expensive computation that does not change between views

The pattern is always the same: check before you compute. Store the result. Serve the stored result on subsequent requests. The storage can be a database, a cache, or even a file. The key is the if not exists check.

For the override-is-sacred rule

Ask yourself: what human action should the system never override?

Common candidates:

Manual corrections to AI output
User preferences and settings
Explicit "mark as reviewed" actions
Human-entered data in a system that also ingests from external sources

The pattern: add a provenance flag. When the human acts, flip the flag. On subsequent automated updates, check the flag. If it is true, skip that field or that entity. Store the original automated value elsewhere if needed for audit.

For the ephemeral presence boundary

Ask yourself: what information is only true at this exact moment?

Common candidates:

Who is online right now
Cursor positions
Typing indicators
Scroll positions
Temporary selections or highlights

The pattern: keep it in memory. Send it via real-time channel (WebSocket, SSE, MQTT). Never write it to a persistent store. On reconnection, re-establish from scratch. Do not try to remember the past.

The test of time

That code has been running since April 27, 2026. The invariants have not changed.

Not because I am stubborn — because they have not needed to change.

The POST-once rule survived a hundred-page-refresh stress test where we simulated 50 users opening the same week sheet simultaneously. One API call. One database write. Perfect consistency.
The override-is-sacred rule survived a project manager correcting the same field seventeen times across two months. The AI was very wrong about that deadline. The flag never failed.
The ephemeral presence boundary survived a WebSocket server restart with zero data corruption. Presence reset. All other data intact. No cleanup jobs needed.

I wrote these rules in 42 minutes on a Tuesday morning. They have saved hundreds of hours since. Not in code complexity — in trust. The team trusts the sheet. The project managers trust the data. The stakeholders trust the status.

That is the real metric. Not API latency. Not database size. Trust.

The code comment

If you look at the original file, there is a comment at the top:

//worked well 27th April 2026 - 08:30 AM - 09:12 AM

That is not a boast. It is a reminder.

Good ideas arrive in focused windows. The trick is to recognize them and write them down as invariants before they slip away. Features can be added later. Invariants are structural. Get them right once, and the system becomes something you can build on for years.

That morning, I stopped adding features. I wrote three rules. I have not regretted it since.

Kiprono Ngetich builds AI-assisted collaboration tools. He thinks too much about data provenance and WebSocket protocols.

The Living Ontology

Rono — Mon, 01 Jun 2026 16:02:46 +0000

A pattern for AI-generated, human-verified project intelligence in real time

Kiprono Ngetich

Ontology is the difference between data and intelligence. A static schema is a prison. A living ontology one that evolves, respects human override, and traces provenance — is the only way to make AI useful in operational environments.

This document describes an ontological pattern built for project status intelligence. But the pattern generalizes.

Any domain where:

unstructured human communication contains structured intent

AI can propose, but humans must verify

real-time collaboration is non-negotiable

auditability is a compliance requirement

...can use this pattern.

The core tension

Every operational ontology faces a fundamental tension:

The AI can extract structure from chaos, but the AI is often wrong. The human knows the truth, but the human won't maintain the ontology.

Traditional solutions fail in one of two directions:

AI-first: The ontology is generated automatically. Humans are viewers. The system drifts. Trust erodes.

Human-first: The ontology is manually maintained. AI is ignored. The system is accurate but stale. Humans burn out.

A third way exists.

The pattern: provenance as the primary axis
Most ontologies organize around what things are. This one organizes around how we know what we know.

Every entity carries a provenance flag: isManuallyEdited.

This single boolean transforms the ontology from a static classification into a dynamic trust layer.

The ontology in minimal form:

text
WeekData
  - contains → Task (AI-extracted)
  - generates → StatusRow (human-editable)
      - has flag → isManuallyEdited (boolean)
      - has lineage → sourceTask (reference)

The critical insight: AI-generated and human-verified are not separate entity types. They are the same entity type with different provenance states.

This means:

The query layer can filter by provenance (show me only human-verified rows)

The AI layer can learn from provenance (rows where isManuallyEdited=true are training data)

The compliance layer can audit provenance (every field has a traceable source: AI or human)

The three ontological invariants
Invariant 1: The POST-once constraint
An AI generation occurs at most once per unique domain entity (in this case, per week).

Why this matters for ontology: Most systems treat AI as an on-demand service. Every view triggers generation. This makes provenance meaningless — there is no "original" AI state to compare against.

This invariant creates a fixed point. The first AI output is frozen as the baseline. All subsequent human edits are deltas against that baseline.

This is the difference between streaming intelligence (ephemeral, unrepeatable) and settled intelligence (auditable, comparable, learnable).

Invariant 2: The override-is-sacred rule
When isManuallyEdited transitions from false to true, the system records the original AI value but never surfaces it again.

Why this matters: In most AI systems, human feedback is treated as a training signal — something that eventually improves the model. In operational environments, that latency is unacceptable. The human correction must be immediately authoritative.

The ontology enforces this at the storage layer, not just the application layer. Even if the AI reruns, it cannot overwrite a field where isManuallyEdited is true.

Invariant 3:** The ephemeral presence boundary**
User presence — who is looking at what right now — is explicitly excluded from persistence.

Why this matters: Ontologies have a tendency to capture everything, including ephemeral state. This creates two problems:

Storage grows with activity, not with domain complexity

Queries become cluttered with irrelevant "current state"

By declaring presence as out-of-ontology, it is forced into a separate channel (WebSocket presence messages). The ontology remains focused on settled truth.

What this enables
For AI operations
The provenance flag creates a natural training loop:

AI generates initial state

Human corrects specific fields

System compares original vs. edited

Corrections become labeled training data

The ontology preserves the alignment between input (raw message) and corrected output (edited row). This is significantly more valuable than generic human feedback — the model can learn why it was wrong by re-examining the original message in light of the correction.

For human operations
Users never see the AI's mistakes. They see the corrected truth. But they can see the AI's original output if they choose — the audit trail is there, just behind a toggle.

This creates psychological safety. The AI is allowed to be wrong. No one is blamed for a bad extraction. The system simply learns and improves.

For compliance
Every field has a provenance chain:

If isManuallyEdited = false, the value came from the AI, which was operating on the rawMessage (stored, immutable, timestamped)

If isManuallyEdited = true, the value came from a specific agent (username) at a specific time, with the original AI value retained

This is sufficient for regulated environments where documentation must meet evidentiary standards.

Comparison with conventional approaches
Concern Conventional ontology This pattern

AI output   Ephemeral, regenerated on each view Fixed point, auditable baseline
Human correction    Overwrites AI output, no trace  Preserves original, flags override
Training data   Separate collection pipeline    Natural byproduct of use
Real-time sync  Out of scope or bolted on   First-class via separate channel
Storage scaling O(views × entities)    O(weeks × projects)

The generalization
This pattern applies to any domain where:

Unstructured inputs (emails, transcripts, logs, messages) contain latent structure

AI can propose that structure with acceptable accuracy (70-90%)

Humans must verify corrections with high confidence

Real-time visibility is required across multiple actors

Auditability is a compliance requirement

Example domains:

Intelligence analysis: AI extracts entities and relationships from raw intelligence; analysts correct and enrich; the ontology tracks provenance

Incident response: AI proposes timeline and impact from alert streams; responders correct in real time; command sees live status

Supply chain visibility: AI extracts shipment status from carrier messages; logistics teams correct exceptions; stakeholders see authoritative truth

Clinical trials: AI extracts patient status from site reports; monitors verify; regulators audit the provenance chain

In every case, the core pattern is the same:

AI proposes. Human disposes. The ontology remembers the difference.

The open question
This ontology is one-way: AI → human → (frozen). There is no closed loop where human corrections flow back into the AI's world model for future extractions, beyond being training data.

The instinct is that the solution lives in the ontology itself: treat isManuallyEdited as a signal that the original extraction should be re-weighted in the model's latent space. But that remains unbuilt.

Closing
A small ontology for a small problem (project status reporting). But the pattern — provenance as primary axis, POST-once generation, sacred human override, ephemeral presence separation — feels general.

It solves the core tension of AI in operational environments: the machine proposes, the human disposes, and the system never confuses the two.

That is not just a data model. That is a trust model.

Kiprono Ngetich

Appendix: Ontology specification (condensed)
Entities:

Entity  Key fields  Provenance
WeekData    weekNumber, year, rawMessage    Immutable after creation
StatusRow   9 content fields, isManuallyEdited, sourceTask  Flag toggles once (false→true)
Agent   agentId, agentType (HUMAN/AI/SYSTEM)    Immutable
EditOperation   oldValue, newValue, timestamp, username Immutable, append-only
Invariants:

(weekNumber, year) unique

AI generation ≤1 per (weekNumber, year)

isManuallyEdited = true → AI never overwrites

StatusSheet.rows indices contiguous

presentIn relationships never persisted

How We Cut Status Reporting Overhead to Near Zero

Rono — Mon, 01 Jun 2026 15:03:53 +0000

A three-week build, three technologies, and one rule we refuse to break

By Kiprono Ngetich

The before

Before building Daraja Workspace, our project managers spent an average of 6-8 hours per week on status reporting.

That's not an exaggeration we tracked it.

The breakdown looked like this:

2 hours chasing updates from team members

2 hours reconciling conflicting information

2 hours formatting reports for different stakeholders

2 hours in status meetings discussing what was already outdated

According to the Project Management Institute, organizations waste an average of 11.4% of their investment due to poor project performance — much of which stems from inadequate communication and status visibility.

We were living that statistic.

The insight

One day, I looked at the raw material our teams were already producing: weekly summary messages, task comments, deadline discussions, Slack threads.

Every single one contained structured project intelligence project names, responsible parties, deadlines, blockers, next steps. It was just trapped in unstructured text, invisible to anyone who needed to report on it.

The insight was simple: the best status report is one that writes itself.

We stopped asking "how do we make people update status sheets?" and started asking "how do we extract status from work people already do?"

The build

We built the first version in three weeks, using three core technologies:

Week    Focus   Technology
1   Real-time collaboration layer   WebSockets + optimistic UI updates
2   AI extraction pipeline  Cohere Command-A + prompt engineering
3   UI + fallback handling  Conditional persistence (POST-once model)

The POST-once model was the key architectural insight: the system calls the AI at most once per week, regardless of how many people view the status sheet. Storage grows by one record per week per project. No redundant API calls. No spiraling costs.

The result

After six weeks of internal use:

Status reporting time: 6-8 hours per week → effectively zero (the sheet maintains itself)

Information freshness: Updated daily via AI extraction + real-time human edits

Team adoption: 100% of active projects migrated

Server cost: One API call per project per week (regardless of view count)

But the numbers don't capture the real change.

The Thursday afternoon panic is gone. Project managers don't chase updates anymore — they read them. They clarify. They unblock. The time they used to spend formatting tables now goes to actual project management.

The rule we refuse to break
Throughout the build, we held one line:

AI writes the first draft. Humans own the truth.

Every AI-generated status row carries a flag — isManuallyEdited — that distinguishes model output from human input. When a project manager corrects a deadline or adds a comment, that change propagates in real time and never gets overwritten.

We don't let the AI learn from corrections in a way that overrides human judgment. The model assists. It does not decide.

What's next
The current system is one-way: AI → humans. Human corrections don't yet flow back to improve the AI's understanding.

We're closing that gap. The roadmap includes:

Two-way feedback loop — AI learns from human edits over time

Export pipeline — one-click PDF and XLSX exports

Cross-week analytics — trend visualization across multiple weeks

Cell audit trails — per-change history with username and timestamp

The broader takeaway
We built this because our Thursdays were broken.

If yours are too, you don't need better templates or stricter deadlines. You need a different architecture. One where status visibility is a side effect of working — not another job.

The information you need is already there. It's in your Slack, your email, your weekly updates, your task comments.

You just need to extract it.

Kiprono Ngetich builds AI-assisted collaboration tools.

Building Real-Time Collaborative Status Sheets with WebSockets and Cohere Command-A

Rono — Mon, 01 Jun 2026 14:38:19 +0000

Conditional persistence, optimistic updates, and why we only call the AI once per week

By Kiprono Ngetich

We wanted live collaboration. We wanted AI-generated status extraction. And we wanted server costs that didn't explode when 50 people opened the same sheet.

The standard approach store everything, recalculate on every view was a non-starter.

So we built something different: a POST-once persistence model where the REST API is a write-once initialization store and WebSockets handle everything else.

Here's how it works, why we chose Cohere Command-A for extraction, and what broke along the way.

1. The core problem

Status sheets die on write.

Traditional project management tools (Jira, Asana, Monday.com) require disciplined data entry from contributors who are primarily focused on delivery. The result is a system that is accurate only when it is actively maintained — creating a secondary task burden on the people least likely to have capacity for it.

Our goal was to flip this: make the status sheet a byproduct of normal work, not an additional job.

2. The WeekData abstraction

The central data structure in our system is the WeekData object, which encapsulates all intelligence associated with a discrete working week.

A WeekData instance carries:

weekNumber (ISO week identifier)

quarter (fiscal quarter)

tasks (ordered list of WeekTask objects)

rawMessage (the unprocessed source text for auditability)

summaryText (AI-extracted executive summary)

The key design choice: WeekData is constructed from a single raw message. This means the platform can reconstruct full week intelligence from one stored message — making the raw WebSocket stream the authoritative source of record.

3. The POST-once model

This is the most important architectural decision.

Before invoking the AI model, the system performs a GET lookup against the persistence API. Generation — and the subsequent POST to persist results — occurs only when the lookup returns no existing data for the current week.

The implications:

Server storage grows at a rate of at most one record per week, regardless of how many users open the status sheet

The AI model is invoked at most once per week, regardless of page refresh frequency

All subsequent changes are propagated exclusively via WebSocket, with no REST API writes

The conditional persistence model sounds obvious in retrospect, but it wasn't obvious at the start. Our first design stored every user's view state separately. For a team of 50 people looking at the same week's status sheet, we were storing 50 identical copies of the same data.

The current design cut storage costs by two orders of magnitude.

Lesson: Cache at the domain level, not the view level.

text
# Generation trigger logic (simplified)
async def get_or_generate_status_sheet(week_id):
    existing = await db.find(f"week_{week_id}")
    if existing:
        return existing

    raw_messages = await fetch_workspace_messages(week_id)
    ai_output = await cohere_generate(raw_messages)
    status_rows = parse_markdown_table(ai_output)

    if not status_rows:
        status_rows = create_fallback_rows(raw_messages)

    await db.post(f"week_{week_id}", status_rows)
    return status_rows

4. AI pipeline: prompt engineering for reliability

We use Cohere's Command-A model (command-a-03-2025), selected for its strong instruction-following characteristics and structured output reliability.

The generation prompt is structured in two parts:

System prompt: Defines the output schema (a markdown table with exactly nine columns) and quality constraints (10-20 word activity descriptions, specific comment formats). The model is explicitly prohibited from adding explanatory prose outside the table structure.

User prompt: Constructed from the WeekData's task list, serialized into structured text that surfaces each task's title, brief, deadline, responsible party, and full detail text.

The model's markdown output is parsed line-by-line with pipe-delimited split and header detection. Rows failing the 9-column minimum are silently dropped.

If the parsed output yields zero rows — due to model refusal, formatting deviation, or network failure — the system falls back to constructing rows directly from the WeekTask list without AI enrichment. This graceful degradation ensures status sheets are always available.

5. WebSocket protocol: five message types

The collaboration protocol is built on three principles:

Operation-based messaging (transmitting what changed, not the full state)

Human-readable formats (pipe-delimited strings that can be logged without a parser)

Optimistic local application (changes apply locally before server confirmation)

The five message types:

Message Type    Format
CELL_EDIT   CELL_EDIT|rowIndex|column|oldValue|newValue|username
BATCH_UPDATE    BATCH_UPDATE|rowIndex|column|value|username
ROW_DELETE  ROW_DELETE|rowIndex|username
ROW_ADD ROW_ADD|{rowJson}|username
USER_JOINED USER_JOINED|username
USER_LEFT   USER_LEFT|username

CELL_EDIT carries both old and new values to enable future conflict detection and undo functionality. ROW_ADD carries a JSON-serialized StatusRow to ensure type fidelity when transmitting multi-field objects.

User presence is maintained client-side as an ephemeral set — presence is a live indicator, not a historical record. Reconnecting clients re-announce themselves, ensuring the presence set self-heals after disconnections.

6. What broke (honest failures)

Three things broke in production:

Model refusal: Occasionally, the model would output "I cannot complete this request" instead of a table. Our fallback to _createFallbackRows() handled this, but we added retry logic with a modified prompt (removing date references) which reduced refusal rates by ~80%.

Formatting drift: The model sometimes added extra columns or merged cells. We made the parser tolerant — it drops extra columns and treats missing columns as empty strings rather than failing the entire row.

Reconnection storms: When the WebSocket server restarted, all clients reconnected simultaneously and re-requested the full status sheet. We added jittered backoff (3s + random 0-2s) to spread the load.

7. What we'd do differently

The biggest missing piece is the two-way feedback loop.

Right now, human edits to the status sheet don't flow back to the AI's understanding of project state. If a project manager corrects a deadline, the AI doesn't learn that it was wrong.

We're building toward this. The isManuallyEdited flag on each StatusRow is the foundation — it tells us which fields represent human judgment vs. AI extraction. The next step is feeding corrected rows back into the prompt context for future weeks.

Other improvements on the roadmap:

Operational transforms or CRDTs for concurrent cell edits

Per-cell audit trails (username + timestamp)

Export to PDF and XLSX

Closing
The system isn't perfect. The AI misses context sometimes. The WebSocket protocol doesn't yet handle concurrent cell edits with operational transforms.

But the core pattern — conditional persistence, operation-based messaging, graceful AI degradation — has proven reliable across months of internal use.

If you're building a collaborative, AI-assisted document tool, steal the POST-once pattern. It's the difference between a demo and a deployment.

Kiprono Ngetich builds software at the intersection of AI and collaboration.

How this Game is won

Rono — Wed, 25 Mar 2026 20:49:40 +0000

A playbook from the greats

Most people think this game is about talent...it’s not, it’s about understanding how things actually move.

Let’s not dress it up.

This is a game.

Not a fair one.
Not a clean one.
But a game you can learn.

So forget the noise.

Let’s break it down.

First thing:

Nothing you see working today started from a good position.

Not the banks.
Not the deals.
Not the people you think had an advantage.

It started the same way every time:

Pressure.

Look at Mwai Kibaki.

He’s already inside the system. Smart. Respected.

Then he loses.

Twice.

That usually ends careers.

He doesn’t react the way people expect.

He doesn’t get louder.

He steps back.

Watches.

Waits.

Lesson one:
When you can’t force the outcome, control your position.

Timing beats effort when the system is bigger than you.

He understood that.

So when the window opened—he didn’t scramble.

He stepped in.

Now James Mwangi and Peter Munga.

They walk into something broken.

Not struggling—broken.

No capital. No trust. No momentum.

Everyone says: shut it down.

They ask a different question:

What’s actually missing?

Not money.

Access.

So they remove friction.

No minimum balance.
No intimidation.
Just access.

Lesson two:
Find the constraint. Remove it. Scale what opens up.

They didn’t build a better bank.

They built a bigger door.

Now Chris Kirubi.

He builds something real.

Then it collapses.

Not because he didn’t try.

Because he didn’t control the system around it.

Distribution blocked. Doors closed.

That’s when it clicks.

Lesson three:
If you don’t control movement, you don’t control outcome.

Product is not power.

Access is.

He adjusts.

Everything changes after that.

Then Gideon Muriuki.

He inherits failure.

Mess everywhere.

Most people try to grow out of problems.

He doesn’t.

He slows down.

Fixes structure.
Fixes people.
Fixes discipline.

Only then does he scale.

Lesson four:
Speed without structure kills you. Fix first. Then move fast.

Now Jimmy Wanjigi.

Different play.

He doesn’t start with assets.

He starts with insight:

The biggest opportunities sit behind government.

So he doesn’t build blindly.

He connects intentionally.

Lesson five:
In this game, access multiplies everything.

Ignore that, and you stay small.

Understand it, and things move faster.

Now zoom out.

Different people.

Different styles.

Same game.

Here’s the pattern:

1. Go where others aren’t paying attention
That’s where the opportunity hides.

2. Stay longer than feels comfortable
Most people leave right before things shift.

3. Change angle, not just effort
Pushing harder isn’t always the answer.

Positioning is.

4. Understand power, not just product
Execution matters.
But control decides scale.

5. Build structure before growth
A weak base doesn’t survive success.

6. Treat relationships as infrastructure
Not optional. Not extra.

Core.

7. Use failure as feedback
Not identity. Not a stopping point.

Just data.

That’s the playbook.

No hype.

No shortcuts.

Now the part people avoid:

This system isn’t designed to be fair.

It rewards awareness.

It rewards timing.

It rewards people who understand how things actually move—not how they should move.

So you decide.

Sit outside the system and complain.

Or step inside it and learn the rules.

And if you’re in the middle right now—

Things not working.
Plans not clicking.
Nothing moving the way you expected—

Good.

That’s where this starts.

You’re not late.

You’re early in the real process.

So don’t rush.

Don’t panic.

Just get sharper.

Where’s the real constraint?
Who controls movement?
What position are you building?
And are you staying long enough to catch the shift?

Now let’s go one level deeper.

Because this is where most people break.

The Rules You Don’t Get Taught

No one is coming to save you
Not systems.
Not luck.
Not perfect timing.

You can benefit from them.

But you can’t depend on them.

Build like it’s on you.

Think inward before outward
Blame is easy.

Control is harder.

Focus on what moves with you:

Skill.
Time.
Execution.

That’s your leverage.

Be selective with people
Some people drain you slowly.

Others sharpen you fast.

Choose carefully.

Distance is not disrespect. It’s strategy.

You will need a level of selfishness
You won’t grow if you’re constantly adjusting yourself to fit others.

There are moments you choose your path over approval.

That’s part of the cost.

Focus beats everything
Discipline gets you started.

Obsession keeps you going.

The people who win stay longer on the same problem.

They go deeper.

Results change how people treat you
Before results, you explain yourself.

After results, people explain you.

So build. Don’t argue.

If you don’t create value, your voice stays small
The world listens to output.

Not intention.

Not talk.

Become useful. Then visible.

Courage is staying when it’s uncomfortable
Fear will be there.

Doubt will be there.

That’s not the signal to leave.

It’s the signal you’re in the real part.

Use what you have
Your environment is not just a limitation.

It’s also an angle.

Find it. Use it.

Kill the scarcity mindset
If you think opportunities are rare, you hesitate.

If you hesitate, you miss them.

Train yourself to see more. Move faster.

Drop the anchors
Bad habits.
Wrong environments.
Time-wasting loops.

You don’t rise while holding everything.

Let things go.

That’s the layer most people avoid.

Not because it’s complex.

Because it demands change.

You don’t need perfect conditions.

You need clarity.

You need focus.

And you need time in the game.

That’s how this game is won.

When Ai runs your Workflow

Rono — Tue, 24 Feb 2026 18:03:41 +0000

What happens when your workspace thinks with you?
"One of the ways that I believe people express their appreciation to the rest of humanity is to make something wonderful and put it out there." — Steve Jobs
We built Daraja Workspace because we kept running into the same wall — and we suspected every team did too.
The brief is somewhere in the chat. The feedback is buried three threads down. The decision that took two hours to reach last Tuesday? Nobody can find it. Meanwhile the deadline is tomorrow, the client is waiting, and half the team is spending more time looking for context than actually doing the work. It's not a people problem. It's a workflow problem. And most tools aren't built to solve it — they're built to store things, not understand them.
That's the gap Daraja Workspace was built to close.

A workspace that keeps up with how teams actually work
Real teams don't work in neat, linear steps. A brief comes in, someone has a question, a thread goes sideways, a new idea surfaces, the scope shifts. By the time you're ready to execute, the important information is scattered across dozens of messages and nobody has a clean picture of where things stand.
Daraja Workspace is built around an AI — DarajaAI — that lives inside the workspace and pays attention to all of it. Not as a chatbot you have to prompt, but as a thinking layer running quietly underneath the work. When a new brief lands, it connects it to everything relevant that came before: the last campaign for that client, the feedback that never made it into the brief, the resource conversation from two weeks ago that everyone half-forgot. It keeps the full picture in view so your team doesn't have to.
When a deadline is approaching, it notices. When feedback in a long thread is contradicting itself, it surfaces the conflict and summarizes what was actually said. When a team member joins a project late, they don't have to scroll through weeks of chat to get up to speed — the workspace can bring them current in minutes.
None of this requires anyone to learn a new system or change how they naturally communicate. The team keeps working the way they work. The workspace gets smarter as they do.

Built for the people doing the actual work
One thing we were deliberate about: Daraja Workspace had to work for everyone on the team, not just the people who already have everything in their heads.
For a junior coming onto a project, that means getting context explained clearly — what the client expects, what's been tried before, what the team's shorthand actually means. For a senior managing multiple projects, it means being able to get a clean cross-project overview without having to dig for it. For the founder or team lead who steps away for a few hours, it means the workspace holds the thread so nothing important drops while they're gone.
The point isn't to automate the work. The creative instinct, the client relationship, the judgment call that turns a good campaign into a great one — those are human, and they should stay that way. What Daraja Workspace handles is the connective tissue: the tracking, the remembering, the surfacing of what matters right now. The mechanics that eat up time and mental energy without adding anything to the actual output.
When that friction goes away, something shifts. The team's attention goes back to the work itself. Conversations get sharper. Decisions get made faster because everyone already has the context they need. The energy that used to go into managing chaos goes into building something worth being proud of.

What we've learned building this
We've tested Daraja Workspace with real teams, on real briefs, under real deadline pressure. What surprised us wasn't how much the AI could do — it was how quickly teams stopped thinking of it as a tool and started treating it as part of the team.
Not because it's trying to be human. But because it's genuinely useful in the moments that matter: when a thread gets too long, when the context is getting lost, when someone new needs to get up to speed fast, when the team needs to move and nobody has time to call a meeting.
We've also learned that the best version of this isn't the AI doing more — it's the AI knowing when to step back. The workspace should feel like a calm, organized colleague, not an interruption. So we've been careful about what it surfaces and when, making sure it adds signal rather than noise.

Why we built this
There's a version of work that most teams glimpse occasionally — usually during the best projects, with the best teams — where everything just flows. Everyone knows what they're doing, information moves freely, decisions happen quickly, and the energy stays high from start to finish. It doesn't feel like chaos management. It feels like building something.
That version of work shouldn't be rare. It shouldn't depend on having the right people in the same room at the same time or a team lead who holds everything in their head. It should be the default.
Daraja Workspace is our attempt to make it the default. To take the things that make the best teams work well — shared context, clear communication, a sense of where everything stands — and build them into the workspace itself, so they don't disappear when the project gets complicated or the team gets busy.
We put it out there because we believe work can feel better than it usually does. And we think the right workspace is a big part of how you get there.

Daraja Workspace is built for teams that care about how they work, not just what they produce. If that's you, we'd love to show you what it looks like in practice.

Check out my app

Rono — Fri, 26 Dec 2025 07:20:41 +0000

Hey guys, this is the shortest article I'll probably ever write...

I've been juggling a crazy schedule lately—work, life, school, endless meetings—and got fed up with clunky calendars and scattered notes.

So I built Rucks an app that uses AI to smartly schedule your chaos, suggest optimal times, and make collaboration effortless.

It's simple, powerful, and actually helpful.

Check it out, try it free, and let me know what you think. Feedback welcome—I'm iterating fast!

Thanks for reading (all 100 words of it). 🚀

The unfair advantage your classmates already have

Rono — Sun, 07 Dec 2025 20:51:11 +0000

I’m not launching anything today. I just want every student in the US, South Africa ,Europe and Kenya who’s currently panicking about finals to know this exists.

Real stories from the last 48 hours (names removed because they begged me 😂):

→ Final-year BCom student at UCT dumped 400+ pages of Econ 301 + 302 slides + tutorial answers into Rucks this morning. Typed: “Generate all my macroeconomics questions and answers for revision.” 30 seconds later he had 127 exam-style questions with full model answers pulled straight from his own notes + past papers he uploaded last year. He’s revising right now instead of crying.

→ Riara University dude in Nairobi facing Microeconomics CAT tomorrow: “Bro just type ‘give me 50 multiple-choice questions on elasticity from my notes’” → Rucks scanned everything he ever saved, made the MCQs, gave the answers + page references. He sent me a voice note screaming.

→ UCLA kid grinding for Econ 101 final next week: Uploaded every lecture recording since September. Typed “create a 3-hour past-paper style exam with solutions from everything we’ve covered.” Rucks delivered a 25-question paper + marking scheme in under a minute.

This isn’t some future AI fantasy. This is live right now at rucks.cc and it costs $1.50 a week.

How it actually works for finals week:

You throw in everything — PDFs, lecture recordings, WhatsApp voice notes from group study, photos of whiteboard, past papers, whatever.

When you’re cooked and have zero time left, you just say stuff like:

“Generate 100 KCSE-level Biology questions from my Form 3 & 4 notes” “Make me a full Principles of Accounting mock exam with answers” “Give me every single definition + example we ever learned in Development Economics” “Turn my International Finance notes into Anki cards”

Rucks reads ONLY your stuff (100% private, nothing sent to OpenAI) and spits out perfect revision material instantly.

$1.50 a week. Cancel anytime. Works offline during loadshedding or when campus Wi-Fi dies.

If you’re in the USA, South Africa, Kenya, or anywhere else on Earth and you have finals coming, stop suffering.

Go to rucks.cc → sign up in 9 seconds → throw your notes in → type “generate all my [subject] questions and answers” and thank me later.

No upsells. No “launch discount.” Just the tool that’s already saving thousands of students right now.

Drop your country flag + the subject you’re currently scared of below. I’ll personally send the top 10 most panicked people a free month.

You’ve got this. Your notes have you covered. Rucks just makes them talk back.

rucks.cc

(like so someone who actually needs this sees it before their exam tomorrow ❤️)

10 Productivity Hacks to Boost Your Day with Rucks

Rono — Sun, 16 Nov 2025 07:31:05 +0000

10 Productivity Hacks to Boost Your Day with Rucks.cc

Are you tired of feeling overwhelmed and struggling to stay on top of your tasks? Do you wish there was a way to maximize your productivity and achieve a better work-life balance? Look no further than Rucks.cc, the AI-powered schedule and task manager that's here to revolutionize your daily routine.

In this article, we'll share 10 productivity hacks to boost your day with Rucks.cc. From prioritizing tasks with AI to reviewing and adjusting your schedule, these tips will help you get the most out of your day.

The Productivity Hacks

1. Prioritize with AI

Let Rucks.cc's AI-powered scheduling feature organize your tasks and schedule. By prioritizing your most important tasks, you'll ensure that you're focusing on what matters most.

Pro tip: Tag tasks with high, medium, or low — Rucks AI pushes deadlines automatically.

2. Task Bundling

Group similar tasks together to maximize your time. Whether it's checking emails or making phone calls, task bundling helps you stay focused and efficient.

Example: Bundle all admin tasks into a 30-minute "Power Hour" every morning.

3. Time Blocking

Schedule fixed, uninterrupted blocks of time for important tasks. This technique helps you stay focused and avoid distractions.

Rucks feature: Drag-and-drop blocks in desktop mode — perfect for deep work on laptops.

4. Break it Down

Divide big tasks into smaller, manageable chunks. By breaking down complex tasks, you'll make progress without feeling overwhelmed.

Rucks hack: Use the "Split Task" button — turns "Write 20-page report" into 5 micro-tasks.

5. Use the Eisenhower Matrix

Prioritize tasks based on urgency and importance. This decision-making tool helps you prioritize tasks into four quadrants:

Urgent & Important
Important but Not Urgent
Urgent but Not Important
Not Urgent or Important Rucks integration: Label tasks with quadrant tags — AI auto-sorts your day.

6. Schedule Self-Care

Make time for activities that recharge you. Whether it's exercise, meditation, or spending time with loved ones, self-care is essential for productivity.

Rucks reminder: Set "Recharge Block" — non-negotiable time that teammates can't override.

7. Avoid Multitasking

Focus on one task at a time for maximum productivity. Multitasking can decrease productivity and increase stress.

Rucks focus mode: Enable "Do Not Disturb" — hides notifications until your block ends.

8. Set Realistic Goals

Be realistic about what you can achieve in a day. Set achievable goals and prioritize your tasks accordingly.

Rucks AI: Suggests daily limits based on your past performance (e.g., "Max 6 high-energy tasks").

9. Use Reminders

Set reminders to stay on track and meet deadlines. Rucks.cc's reminder feature ensures that you never miss a deadline or important task.

Bonus: Get WhatsApp alerts at 7 AM — because email is for old people.

10. Review and Adjust

Regularly review your schedule and adjust as needed. By regularly reviewing your progress, you'll identify areas for improvement and optimize your productivity.

Rucks dashboard: Sunday 8 PM → 60-second review with "What Went Well / What to Fix".

Final Thoughts

By implementing these 10 productivity hacks with Rucks.cc, you'll be able to maximize your time and energy, prioritize tasks with ease, and achieve a better work-life balance.

Kenyan students, freelancers, and hustlers — this is your unfair advantage.

Get Started

Website: https://rucks.cc
Sign up in 3 seconds with Google
First 100 users get PRO free till Jan 2026

"Rucks turned my chaotic semester into a system. Group projects? Done in 48hrs." – Mercy, UoN

Tag a friend who needs this.

Let’s make 2026 the year of done > perfect.

productivity #ruckscc #softwaredevelopment #ai

Posted on November 16, 2025