Language can imitate meaning.
what happens when data gets processed and what happens when this happens through the glorified filter of artificial intelligence?
A conversation about technology, care, interpretation and the ownership of human stories.
freeing the parrot is not a simple, nimble project that came out of an overthinking session, but something that I have always been sitting with.
what happens when data gets processed and what happens when this happens through the glorified filter of artificial intelligence?
what happens to representation of people, their gender, culture and stories when everything is parsed through an algorithm that is coded using binary rules, and ‘if…then…else’?
the first thing I did, post guidance from both arko and paul was to decide what interactions formed primary – input, parrot, data output.
A point of entry into the interaction.
The parrot responds and sustains the encounter.
Signals are interpreted after the conversation.
The encounter raises questions about what a system can claim to know.
my transdisciplinary project at Chamba sort out to gather conversations from the field on how people perceived menstruation, menstrual hygiene and care and the underlying superficial reverence towards superstition and fearmongering of what happens when the menstruating body crossed the thresholds that were set to contain it?
from there my query developed to understanding how taboos, narrowmindedness towards care informed the larger policies at the institutional level
and so I worked at a hospital in Chennai for a month to understand how does this happen and much to my surprise, care is prioritized based on who pays more, who has influence at both the societal level and the financial level, and how does the notion of care take shape for them.
i usually get my concepts by looking at life experiences but interestingly, a significant proportion of them are also derived from tv series and movies and hence “Person of Interest” by Jonathan Nolan played an important role in driving my ideas for the concept of ftp.
poster imagery sourced from the supplied reference images; colour grading and halftone treatment applied for this case study. links above provide film and series credit references.
i built the legacy version of ftp for my core studio ‘By any Media necessary’ led by Manuel Beltran as a sarcastic jibe on how people looked at an AI chat bot as an emotional source of support (“Her” movie; (2013)) and I read on why this was the scenario – why people relied on an AI system to be their emotional support and it all routed back to the questions I asked in my first year; what happens when people remove themselves from care and the idea of providing care?
to understand this further, I had to go back to my childhood and teenage days of social isolation and being treated differently amidst my peers and how when the AI boom happened, my own experiences of chatting with the AI and understanding how that seemed to give me the thought of it being an alternative towards paying for a therapist, except
perhaps that was what the idea around ftp was. knowing that the AI in its present form is disappointing and to make it work, would need require for a collective lobotomization of identities and knowledge.
there were too many touchpoints for the user to fully engage in the installation which made ftp1.0 quite the conundrum.
during the pre-seminar break, I took some time on if an opportunity arose to enhance ftp1.0 what would be the changes I make? and the first thing I did, post guidance from both arko and paul was to decide what interactions formed primary – input, parrot, data output.
the project has been designed with the UI inspired from mystic tech and a popular Christopher Nolan movie “The Prestige (2006) where the themes for ftp2.0 are deceptive, speculative and adversarial outlined on the core question of what happens when a machine performs understanding convincingly enough that a human begins to believe it understands them?
challenges the perception that convincing machine behaviour necessarily means understanding.
explores possible futures of human–AI relationships and outsourced care.
introduces friction that unsettles assumptions about machine understanding.
the glitch was designed to be a matter of occasional trust breakages from the user’s end, to mirror the drift offs in human conversations during situations of interactions.
we, as humans tend to zone out during conversations which could potentially falter trust in the other person interacting with us until we recall where we last left, except the recall itself is a distinctly human process, shaped by our attention, memory, context and the effort we make to reconnect with the other person.
moments from building, testing and discussing Freeing the Parrot 2.0.
i learnt that building the frontend and backend separately was only the beginning. connecting the kimi-built interface to the python backend required me to work through api routing, data exchange and production connectivity.
i moved beyond static card displays to server-generated readings, while aligning frontend stages with backend session states, card selection and participant resonance.
i learnt to account for failed api requests, session-start failures and broken interaction flows, ensuring that the participant could recover instead of reaching a dead end.
i realised that a system working locally does not guarantee that it will work in production. i had to troubleshoot vercel builds, api rewrites and the connection between the frontend and render-hosted backend, while testing the complete participant journey.
i extended the system beyond text by working towards incorporating audio transcription and facial-expression evidence into the session pipeline, raising further questions about how different forms of human expression are interpreted by machines.
Kimi was a frontend development tool, not part of the application’s runtime stack. GitHub Codespaces supported cloud-based development, debugging and testing of the Python backend.
The documented issues fall into three categories: conceptual/analysis gaps, integration and lifecycle failures, and deployment/runtime errors. Some required architectural changes, while others were implementation bugs that prevented the existing architecture from running correctly.
| Documented error or gap | Impact on FTP2.0 architecture | Mitigation |
|---|---|---|
| Post-session reading was too deterministic. | The Deep Reader risked producing predictable readings not sufficiently grounded in the participant's conversation. | Expanded post-session analysis through temporal, linguistic and Navarasa trajectory synthesis. |
| Missing temporal trajectory analysis. | The system could not adequately represent how interaction patterns changed across a session. | Added TemporalTrajectorySynthesizer to capture turn indices, timestamps, response latency, inter-turn gaps, repetition and typing/pause signals. |
| Missing linguistic and Navarasa synthesis. | The analysis layer lacked a structured account of linguistic patterns and emotional signals over time. | Added linguistic and Navarasa trajectory analysis modules. A documented limitation remained: default Shanta labels could distort aggregates when no emotion was detected. |
| Insufficient separation between evidence and inference. | The system risked presenting interpretations as directly observed facts. | The audit identified a need for structured INFERRED claims, supporting evidence, confidence and alternatives. The report does not establish that every part was fully completed. |
| Static or weakly contextualised card themes. | Readings could feel disconnected from the participant's actual conversation. | Added conversation-theme extraction and dynamic territories in the backend, with a regression test. |
| Documented error | Impact on architecture | Mitigation |
|---|---|---|
| Frontend and backend were not initially connected reliably. | The interface could not consistently access authoritative backend APIs in production. | Corrected API proxy/routing and connected the frontend to the Render-hosted backend. |
| Frontend relied on static card content or fallback behaviour. | Displayed content could fail to reflect the backend's generated reading. | Wired the frontend to dynamic deck and session APIs, making the server the source of participant-facing cards. |
| The API response stripped semantic_anchor. | The frontend lost information required to present dynamically generated card themes correctly. | Corrected the backend response and added a regression test. |
| Session-start failures could leave the participant stuck. | The interaction could fail before the main experience began. | Added entry-success handling and retry behaviour for initial session-start failures. |
| Frontend stages and backend session states needed alignment. | The interface risked advancing independently of the backend lifecycle. | Aligned participant-facing stages with backend lifecycle states and card-resonance validation. |
| Multimodal input did not always maintain lifecycle continuity. | Audio and facial-expression evidence risked failing to carry through the session pipeline. | Added multimodal continuity and session-archetype checkpointing, fixed lifecycle issues and expanded end-to-end QA. |
| Documented issue | Impact on architecture | Mitigation |
|---|---|---|
| Session persistence was not sufficiently constrained by participant consent. | Session data could enter persistent storage without the intended consent boundary. | Introduced consent-gated session persistence and a consent-controlled persistence lifecycle. |
| Raw dialogue risked being persisted in event writes. | The data layer could retain more conversational content than necessary for ongoing event storage. | Excluded raw dialogue from ongoing Neon event writes and added tests verifying raw Parrot turn events were not persisted. |
| Raw transcripts could appear in Memory Chest reveal snapshots. | Sensitive conversational content could leak into persistent profile/reveal representation. | Added transcript redaction to Memory Chest reveal snapshots. |
| Frontend TypeScript compilation failed. | The frontend could not compile for deployment. | Corrected type handling and an undefined-value issue; the frontend build subsequently passed. |
| Backend startup failures from f-string braces and newline handling. | The Python backend could not start, making its API and dependent session functionality unavailable. | Escaped literal JSON braces and corrected newline escaping. |
| Production API rewrites and deployment configuration were incorrect. | A working frontend build did not guarantee production requests reached the intended backend. | Corrected Vercel API rewrites, the Render backend target and frontend output-directory configuration. |
from heuristic readings to structured analysis. from loosely connected components to a coordinated system. from implicit data handling to explicit boundaries.
perhaps this would be the most important realisation of all, since models like Google AI Studio ran out of credits quickly with me having to have spent 2K in total to save my project for extra credits + 1200/- for cursor start india plan.
So, I had to resort to continuing the last of my cursor credits and finishing the build with v0 by Vercel (by luck, I had $5 worth of monthly free credits) by prioritizing tasks based on the most credits to least credits used and subsequently the impact that the build would have on the overall UX and architecture of ftp2.0.
building frontend and backend separately was only the beginning.
automated tests can verify implementation behaviour; they do not prove that an interpretation is accurate or fair.
limited credits made task prioritisation part of the development process.
The recorded test suite progressed from 205 to 218, 238, 280 and 313 tests across documented development phases. These counts demonstrate expanding automated coverage, not proof that all interpretive or ethical risks were resolved.
the system risked presenting interpretations as though they were directly observed facts, weakening the transparency of its profiling process.
FTP2.0 is a research-through-design prototype. Expanding automated coverage and building a functioning pipeline do not, on their own, validate psychological interpretations or establish participant impact.