DEV Community: Sasivarnan R

One changed link, a different answer: Workweave with FalkorDB

Sasivarnan R — Sun, 18 Oct 2026 15:16:59 +0000

A company approves a new decision. The document changes. An employee's saved plan does not.

Which work now needs review? Which teams are affected? Who can help?

Workweave is an employee workspace built for the Company Brain track of Graph Hacks. Its agent uses FalkorDB to answer these questions from relationships between work, decisions, sources and people.

Source code · Hosted workspace · Graph model and setup

A decision is more than a recent document

The sample story follows three people. Maya is an engineer. Priya approves company decisions. Leo reviews Maya's work.

Maya saved a checkout plan based on Adyen. Priya later approves Razorpay as its replacement. Workweave keeps Maya's original plan and marks it for review. It does not silently rewrite her notes.

A later proposal is not automatically an approved decision. The graph checks approval, service scope, replacement links and source support. Missing or conflicting authority blocks affected actions.

These are synthetic company records. The provider names do not represent real company decisions or live integrations.

What the graph stores

FalkorDB stores the operational context, including assignments, services, decisions, source documents, reviewers and saved plans.

Maya → ASSIGNED_TO → Assignment → TOUCHES → Service
Leo → REVIEWER_FOR → Service
Decision → APPLIES_TO → Service
Decision → SUPPORTED_BY → Document
New decision → SUPERSEDES → Earlier decision
Saved plan → SUPPORTED_BY → Decision
Work item → TOUCHES → Service → DEPENDS_ON → Service

The saved plan retains the decision it used. That identity lets the application detect a replacement without comparing document wording.

The README graph diagrams show the model. The Cypher catalogue contains the queries used by the application.

An agent with checked output

Maya asks:

What changed for my work, who else is affected, and whom should I ask?

The model chooses from four read-only tools:

get_current_decision: check approved guidance and its source.
inspect_saved_plan: compare the saved plan with current guidance.
find_affected_work: follow service dependencies and find linked owners.
find_reviewers: find the people recorded as reviewers for this work.

The model selects observed fact IDs and proposes next steps. The server builds factual text from the checked graph records. It rejects unknown fact IDs, missing authority checks and changed evidence.

The agent cannot approve decisions, save a plan or send messages. Maya makes those changes through explicit actions. This is a constrained tool-planning agent, not unrestricted generated advice.

The assistant opens beside the task. Maya can keep her work visible while she asks a question.

The test: change a relationship, keep the text

The strongest test changes one dependency instead of changing a document.

Before the change, Support has two routes to Checkout:

Support → Checkout
Support → Billing → Checkout

Billing also depends on Checkout. The application finds four affected work items.

Next, the demo removes Billing → Checkout. Billing's task must leave the result. Support must remain, because its direct route still exists.

Evidence	Before removal	After removal
Affected work items	4	3
Billing task BILL-204	Included	Excluded
Support task SUP-310	Included, two routes	Included, one route
Source content	Same content hash	Same content hash

The same question was sent to the configured OpenAI agent before and after this change. Both live answers identified the stale plan and reviewers. The second answer removed Billing and retained Support with one route. Neither run changed Maya's saved plan.

The recorded live result contains the facts, completed tool names and checks. This is two runs on one synthetic scenario, not a general accuracy benchmark.

How FalkorDB finds the paths

Dependency retrieval uses a bounded, directed Cypher traversal. This fragment shows the core path query:

MATCH (w:WorkItem)-[:TOUCHES]->(s:Service)
MATCH p=(s)-[:DEPENDS_ON*0..5]->(root:Service {id:$root})
WHERE all(node IN nodes(p)
  WHERE single(other IN nodes(p) WHERE other=node))
RETURN w.id, w.title, [node IN nodes(p) | node.title]
ORDER BY w.id

The full query also retrieves team and owner links. Results are grouped by source ID so alternate routes do not duplicate work items.

For indirect dependencies, native algo.SPpaths supplies a verified shortest explanation. The bounded traversal retains the alternate routes; a single shortest path alone would not establish that all routes disappeared.

Another database could implement this logic. The point of the test is that FalkorDB relationships control this application's answer. The graph is not a picture added after retrieval.

Design lessons

Approval and freshness are different. Newer text can be an unapproved proposal. Approval must be represented and checked.

Acknowledgement and acceptance are different. Reading a replacement does not mean that an old plan has been updated. Workweave records both actions separately.

One broken route does not remove all impact. Alternate routes matter. The removal test checks retained work as well as removed work.

More context does not guarantee a correct model answer. An earlier paired model diagnostic still produced abstention and citation failures with graph context. That result led to checked fact IDs and server-side action gates. The validation report includes those failures and the method's limits.

What remains

The prototype uses normalized synthetic exports, not live Jira, Calendar or Zoom synchronization. Missing links can hide affected work. Traversals stop after five links. A visitor cookie isolates sample graphs; it is not production employee authentication.

Production work would need identity, permission-aware retrieval, reliable connector updates and operational monitoring. Agent access also needs provider spending controls; an operation limit is not a dollar cap.

Workweave's useful result is a checked connection between a changed decision and the work that depends on it. The employee can inspect the source and choose the next action.

AI disclosure: Codex assisted with implementation, tests, documentation and this article draft. Automated checks are documented separately from participant review. No independent user test or production accuracy claim is made.

SoundSafari: ten seconds of recording, one minute of listening

Sasivarnan R — Sat, 10 Oct 2026 02:29:13 +0000

Built for the DEV Week 1 “Touch Grass” challenge.

What I Built

SoundSafari is a small outdoor listening exercise. You record ten seconds of your surroundings, get a tentative sound category, and use it to choose a short listening mission. Then you put the phone down, listen, and optionally write what you noticed.

The goal is simple: make a familiar place worth paying attention to again.

The first version spent too much space explaining itself. During development, I found myself asking what I was actually supposed to do in the app. That question became the design constraint. The current mobile-first experience has three steps: Capture → Listen → Note. No account, leaderboard, or feed.

Demo

Try SoundSafari — live on OpenAI Sites

The demo is public. Open it directly in your browser for microphone access; no app account is needed.

You can also run the app locally using the repository’s setup instructions. Allow the initial model download to finish, then record while stationary somewhere safe. If microphone access is unavailable, choose a sound you can actually hear and continue manually.

The exercise is intentionally small:

Consent to a ten-second microphone recording, or take the manual route.
Review the model’s suggestions and choose a listening mission.
Spend a minute listening. The optional timer keeps time; the screen doesn’t need your attention.
Write a short reflection, with an explicit choice to save it on this device.

Code

GitHub repository — sasivarnan/sound-safari

The application is MIT licensed. The README documents setup, model provenance, privacy behavior, deployment, and limitations.

How I Built It

SoundSafari uses React, TypeScript, and Vite, with a restrained shadcn interface. Application state lives in @xstate/store: recording, analysis, mission selection, timer, reflection, and persistence all respond to explicit events. Small screen transitions and recording feedback respect reduced-motion preferences.

For the core AI feature, I used Xenova’s Audio Spectrogram Transformer checkpoint, an AudioSet sound classifier, through Transformers.js. A worker runs quantized inference locally in the browser using WASM.

That choice has a real cost: the first visit needs roughly 90 MB of model weights, plus runtime assets. It also means captured audio does not need to be sent to a server for classification. The model download requires a network connection, and browser caching does not make this a guaranteed offline app.

The output is a suggestion, not a verified description of a place. Wind, overlapping sounds, and unfamiliar recordings can confuse the classifier. SoundSafari handles silence, low confidence, failed model loads, and denied microphone access without inventing a result. The manual route remains available.

Missions are curated prompts selected from the chosen sound category. They are not generated by a language model. That keeps them short and predictable. They ask you to notice what you can hear from a safe position; they do not give walking directions or ask you to approach a sound source.

Privacy also affects the lifecycle: the app stops an active recording when the page is hidden, ignores stale asynchronous results after cancellation, and releases microphone tracks. Reflections stay in the current session unless the user opts into local persistence. Saved entries can be cleared; recordings are not saved with them.

Two community discussions informed the reliability work: orca_forge’s browser audio pitfalls guide prompted attention to microphone lifecycle, and ryanlee91’s abortable state article reinforced the need to reject late responses. I applied those principles to recording and model runs rather than copying their implementations.

Validation so far: 18 automated tests pass, the production build passes, and synthetic model smoke checks ran in Node and a browser worker. These checks establish that the pipeline runs; they do not establish outdoor classification accuracy. Real outdoor sessions and broader mobile-device testing are still needed. This is an MVP, not a species identifier, navigation aid, or safety monitor.

AI assistance was used for implementation, debugging, and drafting this post. The product direction and revisions came from the development conversation; this post makes no claim of field observations that did not happen.

Why Does Open Innovation Matter?

Open weights made it practical to build a useful sound-analysis feature without collecting people’s recordings. They also make the model choice inspectable: another developer can find the checkpoint, understand its training context and license, and replace it if it performs poorly for their environment.

That openness does not remove limitations. Model size, device performance, and uncertain predictions still shape the experience. In SoundSafari, those constraints led to an honest fallback and a smaller interaction: use the model to start paying attention, then let the person do the listening.

The next useful step is to try that interaction outdoors with a few people and see whether it helps them notice something they would otherwise have missed.

Practice the Awkward Bit: rehearse conversations with local Gemma

Sasivarnan R — Sat, 03 Oct 2026 19:27:05 +0000

A submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

I’m an introvert, and sometimes the hardest part of a conversation is getting the first sentence out.

Practice the Awkward Bit gives you a quiet place to rehearse: decline an invitation, ask for something back, or join a conversation. Set the scene, choose how cooperative the other person is, and try a few replies.

Gemma plays the other person. When you finish, it offers one thing you expressed clearly, one suggestion, and another way to say it. “Try this reply again” takes you back to an earlier message so you can experiment.

I built it with fellow introvert people in mind.

Demo

Try the app — currently private, pending access for judges.

Use a desktop browser with WebGPU. Load the model, choose Decline an invitation, and try:

Thanks for inviting me! I’m going to stay in tonight, but I’d like to join you another time.

Then ask for a reflection or retry your reply. The first model download is large and needs internet.

Code

Source on GitHub · MIT license for the app.

How I Built It

React, TypeScript, and Tailwind CSS 4 handle the interface. Gemma 2 2B runs locally through WebLLM, in a dedicated worker.

                  YOUR BROWSER
┌─────────────────────────────────────────────┐
│ React UI · Tailwind CSS 4                    │
│   Scene → conversation → reflection → retry │
│                 ⇅ messages                  │
│ Web Worker                                  │
│   WebLLM → Gemma 2 2B → WebGPU               │
│                 ↑                           │
│ IndexedDB: cached model assets              │
│                                             │
│ Conversation: memory by default             │
│   └─ optional localStorage save / text export│
└─────────────────────────────────────────────┘
          ↑ site and model downloads
     Hosting / model asset servers
     (no conversation inference requests)

Role-play and reflection use separate prompts. Reflection returns structured JSON, and the app checks that its quoted reply actually came from the user.

Model loading, real replies, reflection, rewind, and save/restore worked in the desktop browser test. Tests, type checks, and the build passed. Feedback still sometimes invents details, so it needs judgment rather than blind acceptance.

Why Does Open Innovation Matter?

These conversations can be personal. Running an open-weight model locally keeps the transcript out of an inference API and avoids a per-conversation API bill.

I can also inspect the prompts and swap supported models. The tradeoff is a large download and dependence on the user’s hardware. This isn’t a fully offline install, and Gemma’s terms still apply.

Rahul’s post on browser-local LLMs helped frame the worker and loading experience.

Prize Categories

Best Use of Gemma: Gemma generates both the conversation partner and the reflection.

Credits

Google Gemma, MLC AI/WebLLM, React, Tailwind CSS, lucide-react, and the Sites/Vinext starter.

Codex helped build, debug, test, and draft this post.