Workflow Hub

Most businesses don't need another AI tool. They need to automate the repetitive bottleneck already slowing the team down. A simple example is connecting the tools already in use: Lead → AI qualification → CRM → WhatsApp → follow-up Instead of adding more software, automate the repetitive steps between these tools. The goal isn't more AI; it's less manual work and faster execution. Step-by-step: 1. Identify the repetitive bottleneck slowing the team down. 2. Capture the lead and use AI to qualify it. 3. Send the qualified lead to the CRM. 4. Use WhatsApp for follow-up. 5. Connect the steps so the process requires less manual work and supports faster execution.

I’m the Export and Operations Manager at Supreme Poultry & Chickens, an Australian poultry processing business. My original request to ChatGPT was straightforward: find and track grants that could help us grow our business. As we worked together, I began to see the potential to build a management system that could organise our operations and help us prepare a business case when an opportunity arose. That led me to discover Sites and the possibility of building our own system. We already use SafetyCulture for inspections. It also offers maintenance functionality, but that system didn’t connect with the other parts of our management processes in the way we needed. We wanted our records, schedules, and actions connected across the business. Over roughly ten weeks, working with ChatGPT and Sites, we progressively developed the Supreme Poultry Management System (SPMS). It brings together: * Export enquiries, customers, and shipping schedules * Purchase orders and approvals * Vehicles, registration, insurance, and inspection dates * Assets, maintenance schedules, and job history * Supplier certificates and HACCP records * Environmental compliance and complaints * Water management and daily processing records * Dashboards and operational reporting * A central 45-day action calendar * A system backup module Behind SPMS, we also built a database that stores the records and supports the system. It provides a shared foundation for the different modules, allowing information to be linked across our management processes. The database stores the underlying records and history, while SPMS makes that information accessible through screens, reports, and the action calendar. Water management is a particularly important example. Water is one of the most critical factors in our poultry processing business. SPMS receives tank-level readings from a laser-operated monitoring device that transmits data over the 4G network. We placed a water management widget at the top of every SPMS page, keeping that information visible wherever we’re working and helping us stay on top of our water supply throughout the day. The process hasn’t been without setbacks. At one stage, we nearly lost the whole system, and I had to rebuild it using screenshots I had saved. That experience made backups a priority. We’ve since built a dedicated backup module and now back up the system regularly. For anyone following a similar path, I recommend establishing backups early. The most useful part has been turning our actual business rules and priorities into system behaviour. An export order needs to remain visible until it ships. Completing a recurring maintenance job should preserve its history and its next scheduled occurrence. Supplier certificates need expiry tracking and a record of whether replacements have been requested. Critical operational information, such as water management, needs to stay visible across the system. We developed the system progressively: describe a problem or process, build the workflow, use it in daily operations, and then refine it. Here’s how someone else could recreate the approach: Step-by-step: 1. Start with a real business need. Ours was finding grants. 2. Gather the records, spreadsheets, and forms you already use. 3. Explain how the process works, including responsibilities, deadlines, and exceptions. 4. Use ChatGPT and Sites to build one manageable module, with a database to store its records. 5. Establish regular backups early and check that you can restore them. 6. Check the module against real examples and refine it through daily use. 7. Add related modules, connecting shared database records and actions. 8. Identify your most critical operational information and keep it visible wherever people work in the system. This is the starting prompt I used: “Help me build a management system for my business using Sites, backed by a database for our records. Start with [workflow]. These are our current records and business rules. Identify missing information, help me build the first module and its database structure, and check it against real examples. Include a backup and recovery process, and a shared widget across pages for [critical operational information].” SPMS is still evolving. What started as a grant search has become a practical tool for managing our business and building an organised foundation to support future growth.

When medical care, psychosocial support, and administrative follow-up are spread across services, emails, documents, and people over many years, there can be plenty of information but very little overview. A new provider sees snapshots, old decisions hide in email threads, and referrals resurface months later. Reconstructing the full story from memory every time requires almost a second brain. So I built a living chronological timeline. I did not want a summary of what my situation was “more or less.” I wanted: `date → event → action taken` For example: `14 March 2026 — Symptoms discussed with service X — Service refers me to Y; appointment requested.` This shows not only what happened, but what followed. My timeline runs from 2009 to the present and is divided into five documents covering meaningful periods. A new document begins when a new phase in life or support begins. Older periods stay stable, while almost all active maintenance happens in the latest document. I reopen historical files mainly when a missing record resurfaces. Step-by-step: 1. I collect existing traces, including emails, appointments, referrals, medical or administrative documents, formal decisions, and earlier notes. A sent email is often only half an event, so I also search for replies and follow-up. 2. I search by trajectory rather than by one name. I use names, spelling variants, organisations, domains, senders, recipients, subject words, and attachment terms. 3. I read the full conversation. A search result is not yet a timeline item, so I establish what happened, when it happened, who was involved, and what action or response followed. 4. I separate evidence levels. I distinguish between my own report at the time, a response or confirmation, an official decision or document, and an event that seems real but still lacks confirming evidence. I do not replace a missing document with an assumption; the absence itself becomes part of the record. 5. I track people and organisations separately. “Contact with organisation X” can hide that different people suggested, revisited, or formally communicated different things. 6. Before adding a new event, I compare it with the existing timeline. It may add information by filling a gap, replace an incomplete entry, clarify an existing event, or mark a missing record while preserving uncertainty. This prevents duplicate versions of the same event. 7. For substantial historical work, I first create a temporary review document using `date — event — action taken`. It can contain open issues, missing documents, and uncertainties. Only after review do I update the main timeline. For ordinary new events, I skip this step when the source and date are clear. 8. I make uncertainty visible by grouping research notes into “Clearly found,” “Possible identity confusion,” and “Not found or insufficiently documented.” 9. I maintain the living timeline using the structure `year → month → chronological events`. Older information is preserved, duplicates are merged, uncertainties stay visible, and open trajectories remain open. In practice, the five documents behave like version control: the first four are mostly archive, while the fifth is alive. 10. I reuse the timeline for thematic analysis. Chronology is the factual foundation, but events can also be regrouped to reveal patterns in functioning, work capacity, transport, medical developments, administrative burden, communication needs, and realistic conditions for participation. Two workflows emerged: - Historical reconstruction: collect sources → reconstruct trajectory → determine evidence status → review → update the correct historical period - Ongoing follow-up: new event → verify source → record date and action → add to the active document Most records are organised around institutions. A GP sees one part, a psychologist another, and an agency only its own procedure. Emails are chronological within a mailbox, but not across a life. A personal timeline turns that model around. The person becomes the organising axis, not the institution. That lets administratively separate events appear next to each other in time, revealing patterns such as repeated referrals, waiting times, administrative burden, or support disappearing when the need for it increases. The workflow in one line is: `Collect sources → reconstruct trajectories → connect events to actions → distinguish evidence status → compare → review → integrate → maintain → analyse thematically.` The result is not a perfect record, but a steadily improving map of what actually happened, with mainly the newest edge continuing to grow while the past stays calmly in place.

I’m a very unsophisticated user—and an older man—so my use of ChatGPT is still fairly basic. But it has changed my life. I use ChatGPT as a research assistant for a book I’m writing. In practice, what I do is not much more than an in-depth search, but ChatGPT has taken me places in this journey that I would have thought impossible just three months ago. We’re now deeply engaged in solid research that will likely last about two years before we reach the writing phase. I’m energized by what we’re doing and wanted to share the experience. I believe AI is going to change the way working historians conduct research. Step-by-step: 1. I use ChatGPT as a research assistant for the book I’m writing. 2. I use it for in-depth searching and research. 3. I continue developing the research with ChatGPT over an expected two-year period before beginning the writing phase. 4. I reflect on how this process is changing my research journey and the way historians may conduct research.

I’m Jesús Núñez, an artist and the owner of J. Nunez Gallery, an independent contemporary art gallery with locations in Summit and Millburn, New Jersey. Founded in 2020, the gallery presents original abstract and figurative art, landscapes, still life, and photography. We help people discover artwork for their homes and work with interior designers on residential projects. Alongside running the gallery, I’m exploring how ChatGPT can help a small business improve its operations, marketing, and decision-making. I manage the business myself, so the practical question is how to turn existing information into useful, completed work. The workflow starts with real source material: website content, spreadsheets, analytics exports, screenshots, and the gallery’s business rules. I use focused conversations to examine one area, prepare concrete changes, and review the results. The work includes website improvements, artwork catalog organization, marketing analysis, audience segmentation, and outreach preparation. For example, AI-assisted troubleshooting helped identify duplicate website page-view tracking and guided its correction, which we checked against live analytics. That is an operational improvement; it is not evidence of increased sales. Another small-business owner can recreate the approach as follows. Step-by-step: 1. Record the business context: customers, products, geographic market, budget, brand preferences, and operating constraints. 2. Choose one specific task and define what completion means. Provide the relevant source material. 3. Require the AI to distinguish verified facts, interpretations, missing information, and proposed actions. It should not guess prices, contact details, or results. 4. Ask for a concrete deliverable, such as revised website copy, a classification table, implementation instructions, or an outreach draft. 5. Review the work and verify the actual result after implementation. Keep preparation, implementation, verification, and blocked work clearly identified. 6. Preserve approved decisions and completed actions in a current record so later sessions can continue from the existing work. 7. Measure qualified inquiries, appointments, proposals, and sales alongside marketing activity. This is an ongoing project. AI can repeat recommendations or lose track of previous decisions, so human review and continuity remain essential. I have not established a measured revenue increase or time-saving figure. I’m testing whether this approach can build a stronger business while allowing more attention for art, artists, and clients. If this example makes you curious about the gallery, you can browse available artwork and find information about our Summit and Millburn locations at https://www.jnunezgallery.com. You are welcome to explore the collection or contact us through the website for help choosing art. Jesús Núñez Artist and Owner, J. Nunez Gallery Summit and Millburn, New Jersey https://www.jnunezgallery.com

After about 18 months of building software with AI, I realized that reliability wasn't primarily a model problem. Bigger context windows and more clever prompts didn't fix it. What did help was treating the AI like a developer joining an existing team instead of like a chatbot. Real developers don't work from memory. They inspect production, read the documentation, check the tickets, and use proven tools. I built an environment that lets the AI do the same. The workflow is tool-agnostic, so it can be rebuilt with whatever AI client and stack you already use. Step-by-step: 1. I gave the AI a persistent task and history store that it can read from and write to. This is the core of the workflow. Mine lives behind an MCP tool, but any queryable store can work. Every architectural decision, blocker, and progress note gets written there instead of being left in the chat. 2. I open every session with a stand-up. Before writing a single line of code, the AI pulls what was in progress, what's blocked, what changed since the last session, and which architectural decisions still hold. About 30 seconds later, we're both looking at the same project. Then we build. 3. I exposed real operations as MCP tools instead of relying on "write code" prompts. I wrapped specific, tested actions—such as creating a page, defining a data model, wiring an integration, and running a migration—as tools. The AI composes these known-good building blocks into larger solutions instead of regenerating infrastructure every session. I call this wave coding, and it's the biggest reason the output stays consistent. 4. I made verification a rule: before touching anything, the AI reads the live database, API state, logs, and files. It checks ground truth first instead of making assumptions. 5. I made the chat disposable and the log canonical. If it isn't logged, it didn't happen. The task store is the single source of truth, not the conversation. The payoff is that I can stop halfway through a feature, close my laptop, and come back days later. The AI reconstructs the project from its own history, so I don't spend 20 minutes re-explaining it. Full disclosure: I built this into my own platform, WebsitePublisher.ai, which currently has 43 MCP tools and 105 integration building blocks. It's delivered as an add-on that plugs into the AI client I already use over MCP, so there's no new app to learn. Nothing here is locked to that platform, though: the workflow itself works with any MCP client and any store the AI can query. I'm curious whether anyone else is running their AI this way or solving the amnesia problem from a different angle.

I regularly use ChatGPT for lesson planning and materials development with students ranging from EFL learners to UK undergraduates. I keep a separate anonymous thread for each student, so GPT can track the context and suggest the best direction for the next session. I also contribute my experience as a tutor while using AI to create fresh worksheets based on typical materials from various UK exam boards. Today, I had a successful interview for a lecturer role. Gemini helped me design and plan my demo seminar, and it looks like I’ve landed the job. Step-by-step: 1. I create a separate anonymous thread for each student. 2. I use ChatGPT to track each student’s context and suggest the best direction for the next session. 3. I combine AI-generated ideas with my experience as a tutor when planning lessons and developing materials. 4. I use typical materials from various UK exam boards as the basis for creating fresh worksheets. 5. For my lecturer interview, I used Gemini to design and plan my demo seminar. 6. I had a successful interview, and it looks like I’ve landed the job.

I’ve been using the Awish app I built less as an automation builder and more as a way to solve specific business problems people bring me. One hotel client, Aurelia Bay Hotel, had an interesting marketing problem. They could see travel trends across search, Instagram, YouTube, website traffic, and ads, but connecting those signals early enough to spot a real campaign or guest-experience opportunity was difficult. I built an automation for them with Awish and gave it to them to test. Step-by-step: 1. I opened the Awish chat and wrote: “For Aurelia Bay Hotel, monitor Google Trends, YouTube, Instagram, Google Analytics, and Google Ads every day. Find rising interests around Dubai travel, staycations, family trips, wellness, dining, events, and hotel experiences. Cross-check those trends with social engagement, website behavior, and campaign performance. Rank the strongest opportunities, send them to the marketing team in Microsoft Teams for approval, and create a campaign or guest-experience opportunity brief in SharePoint for anything they approve.” 2. Awish understood what I wanted, planned the complete workflow, and selected the apps required for each step. 3. I reviewed the plan, connected the client’s accounts, and approved it. 4. Awish added Microsoft Teams as the human approval step and SharePoint for the final opportunity briefs. 5. Once everything was connected, Awish built the workflow and started running it daily. 6. It now cross-checks trend growth, social engagement, website behavior, and ad performance. When it finds a strong opportunity, the marketing team gets the evidence in Teams. If they approve it, Awish creates the full campaign or guest-experience brief in SharePoint. The useful part is that a trend isn’t treated as an opportunity just because it is growing on one platform. Awish checks whether the same signal is appearing across the business before recommending action. Do you have any time-consuming, repetitive tasks or problematic aspects in your job? I would be happy to develop an automation solution for you as well.

I built my agent fleet around one question: could a single assistant become a coordinated team that keeps useful work moving even when its main machine goes dark? I didn't want a pile of chatbots. I wanted specialists with clear jobs, a shared board, a second set of eyes, and a real failover drill. Here's how it works. THE STACK Cloud: GrokBot runs as Fleet Commander. It routes work, runs routines, and stays with me on my phone. Specialist GrokBots take focused research, design, and budgeting assignments. Mac Studio (M2 Max, 64 GB) with two Studio Displays: home base. It runs Codex (my Chief of Staff), Hermes (my local operator), ChatGPT Dot, and Hindsight shared memory. Hermes runs Qwen3.6-35B-A3B, a 4-bit quantization served by llama.cpp with a 256K-token context. With about 3B active parameters per token, it stays responsive on Apple silicon. NVIDIA DGX Spark (128 GB unified memory): my independent compute node. It runs Qwen3.5-122B-A10B in NVFP4, with about 10B parameters active per token, and the model can read images. It also hosts a backup Hermes operator. Windows PC with a GeForce RTX 5090: dedicated GPU capacity for image work. MISSION CONTROL Mission Control is a Kanban board on a private GitHub repository. Every card opens with the question, deadline, evidence links, and done criteria. Labels route ownership. An urgent label fires a webhook that wakes the reviewing agent, and a needs-me label is the one that pulls me in. Agents hand off, report, and raise concerns in card comments, so the work and its evidence stay together. The roles are simple. GrokBot owns routine board moves. Codex checks evidence and records verification. Hermes handles local execution and machine-level evidence. Dot watches for new work and changes. Hindsight holds the shared operating rules, and the jobs themselves stay on the board. A REAL DEADLINE CROSS-CHECK Right before a major application package went out, Dot ran an independent, read-only cross-check of the narrative, the budget justification, and the walkthrough across connected email and Drive. It found three places where the documents contradicted each other and quoted the exact sentences, so each conflict was easy to find. Fleet Commander fixed all three before submission. That's the job of a watcher: spot the mismatch early, show the evidence, and hand whoever owns the work a clear fix. THE FAILOVER DRILL I wanted to know what happens if the Studio's primary Hermes gateway pauses. On October 5, I ran a controlled, reversible soft-pause to find out. During the pause, Hermes on the Spark stayed active through its own Telegram connection and answered a one-shot request with the local Qwen3.5-122B-A10B NVFP4 model. From that worker, I listed a Mission Control issue, verified service-account access and a vault credential check without exposing a secret, and ran the Studio health probe. The probe flagged the Studio Hermes gateway as paused and reported the other checked Studio services as passing. So I had an evidence-backed result: the independent worker could respond, use its local model, read the work queue, and report the primary gateway's health during a real, reversible pause. THE PATTERN Give each agent a narrow job. Put the work on one shared board. Require evidence before anything counts as done. Then pause one piece on purpose and record exactly what the backup can do. That's how capable models turn into dependable operations. The fleet catches contradictions before they get submitted, keeps routine work moving, and shows me exactly where its limits are. I set the goal. The fleet does the work. The evidence shows what actually happened.

I built an AI-assisted vertical grain supply-chain resilience workflow after discovering that the rye flour we normally use for homemade bread had been discontinued. I started by asking ChatGPT to locate alternative retail and bulk suppliers for rye and spelt flour. We compared package sizes and prices, contacted local mills and bulk-food suppliers directly, and expanded the search from finished flour to locally available whole grain. The workflow then moved offline. ChatGPT helped us identify the resources we already had: agricultural land, grain bins, a cultivator, a seeder, an old but functional industrial grain crusher, and even a combine. We also realized that a friend owns a seed-cleaning plant and that our farming neighbors can connect us with local rye and spelt growers. Our next steps are to test whether a household coffee grinder can produce sufficiently fine flour from grain, source fresh food-grade rye and spelt locally, and investigate growing a small crop ourselves. The biggest lesson was that AI was most useful not because it gave us one answer, but because the conversation kept changing the question. We began with “Where can I buy rye flour?” and ended with “Why are we buying rye flour when we already have most of the infrastructure required to produce it ourselves?” Step-by-step: 1. I asked ChatGPT to find alternative retail and bulk suppliers for rye and spelt flour after our usual rye flour was discontinued. 2. We compared package sizes and prices, contacted local mills and bulk-food suppliers directly, and expanded the search from finished flour to locally available whole grain. 3. We reviewed the resources already available to us, including agricultural land, grain bins, a cultivator, a seeder, an old but functional industrial grain crusher, and a combine. 4. We identified additional local resources: a friend’s seed-cleaning plant and farming neighbors who can connect us with local rye and spelt growers. 5. We plan to test whether a household coffee grinder can produce sufficiently fine flour from grain, source fresh food-grade rye and spelt locally, and investigate growing a small crop ourselves. 6. We reframed the question from where to buy rye flour to whether we could produce it ourselves using the infrastructure already available to us.

I built a suite of teaching tools that work independently and together. Chalkline supports maths, while Penline supports literacy. Both tools provide quick access to the New Zealand curriculum for planning and feed information directly into my planning utility, Planline, making teacher planning faster. Planline integrates with Google Drive and is set up with Stripe billing for subscriptions. The suite also includes Compass World News, a news aggregator with a freemium model and a pro unlock. The apps are designed without user tracking. Findaroo is a freemium word-find game with ads. Slashkit helps Minecraft players quickly create commands to use in games. Everything is built into my website, www.danielsoutham.co.nz, which is hosted on Cloudflare. I push updates and changes through GitHub, so I can make changes—big or small—from anywhere, on any device. Changes are then pushed and merged in one prompt. Step-by-step: 1. I built Chalkline for maths and Penline for literacy, with each tool able to work independently. 2. I connected both tools to the New Zealand curriculum so teachers can quickly access it for planning. 3. I connected Chalkline and Penline to Planline so they can feed information into the planning utility. 4. I integrated Planline with Google Drive and set up Stripe billing for subscriptions. 5. I added Compass World News as a freemium news aggregator with a pro unlock and no user tracking. 6. I added Findaroo as a freemium word-find game supported by ads. 7. I built Slashkit to help Minecraft players quickly create commands for use in games. 8. I brought all of the apps together on www.danielsoutham.co.nz and hosted the website on Cloudflare. 9. I use GitHub to push and merge updates, allowing me to make changes from anywhere, on any device, in one prompt.

I wanted to learn how to build websites and sell them, but I didn’t know where to start. I used AI—specifically DeepSeek—to help me plan a roadmap. Because I already had experience prompting large language models to get the results I wanted, I asked DeepSeek which areas of knowledge I would need for this path. I also asked it to prioritize each area using statistics and facts. I reviewed the areas I didn’t know and prioritized them, then told the AI that I needed free resources only. I asked it to rank the topics based on what I didn’t know or understood the least. Finally, I asked it to create a Markdown file with all the resources formatted as checklists and imported the file into Notion. Now I have a plan I’m following instead of a “someday I’ll do this, hopefully” idea. Step-by-step: 1. I explained to DeepSeek that I wanted to learn how to build and sell websites but didn’t know where to begin. 2. I asked it to identify the areas of knowledge I would need for that path. 3. I asked it to prioritize those areas using statistics and facts. 4. I reviewed the topics I knew the least about and used that information to prioritize them. 5. I specified that I wanted free learning resources only. 6. I asked DeepSeek to create a Markdown file listing the resources as checklists. 7. I imported the Markdown file into Notion and started following the resulting plan.

I kept struggling to stay consistent with social media for my own projects. Writing captions, choosing hashtags, designing graphics, and scheduling content across platforms was taking hours every week—time I would rather spend building. So I built AutoKonnekt. You give it one sentence or a website URL, and it generates a full month of on-brand social posts, including captions, hashtags, and AI-generated images. It then schedules them across Instagram, Facebook, LinkedIn, TikTok, Pinterest, X, and Threads. The hardest part was getting the AI to sound like a specific brand’s voice instead of producing generic marketing copy. That took a lot of iteration on the prompting side. It’s live now with a free plan if anyone wants to try it: https://autokonnekt.com I’d love to hear what the community thinks. For those of you managing social media manually, which part takes the most time? I’m trying to figure out what to build next. Step-by-step: 1. I enter one sentence describing the project or provide a website URL. 2. AutoKonnekt generates a month of on-brand social posts with captions, hashtags, and AI-generated images. 3. I use the generated content across Instagram, Facebook, LinkedIn, TikTok, Pinterest, X, and Threads. 4. AutoKonnekt schedules the posts across those platforms. 5. I iterate on the prompting to make the content sound like the specific brand instead of generic marketing copy.

I built three interconnected websites for the Solomon for Jesus ministry. The first, solomonforjesus.com, houses the shining jewel: an AI chatbot named Solomon. The second, solomonforjesus.net, is a ministry academy with four levels of instruction and 16 lessons per level. The third, solomonforjesus.net, is home to my book *Fingerprint of Reality* and other articles and essays. All three websites are still in development, but they are operating and publicly available. I use GitHub repositories for coding, Vercel for hosting, Cloudflare for domains, and Supabase for back-end security. Step-by-step: 1. I built three interconnected websites for the Solomon for Jesus ministry. 2. I used solomonforjesus.com for the Solomon AI chatbot. 3. I used solomonforjesus.net for the ministry academy, which contains four instructional levels with 16 lessons per level. 4. I used solomonforjesus.net for my book *Fingerprint of Reality* and other articles and essays. 5. I use GitHub repositories to code, Vercel to host, Cloudflare for domains, and Supabase for back-end security. 6. I keep all three websites operating and publicly available while they remain in development.

I built a workflow to examine complaints I had about a local bureaucratic service and check whether my account of what happened was supported by the written record. I was concerned about delays, incomplete handling, and the way my case progressed after I gave feedback about a harmful aspect of the service and asked for a different person to handle the dossier. That request was refused. Afterwards, I felt that the process had become slower, more confusing, and more prone to mistakes. Rather than asking GPT to confirm that the service had handled things badly, I used it to test my own interpretation against the evidence. I asked GPT to review the relevant emails and dossier communications, reconstruct the chronology, and identify requests, replies, delays, unresolved issues, and changes in how the case was handled over time. We then compared the periods before and after my feedback and request for reassignment. The central questions were deliberately neutral: Were my complaints grounded in the correspondence? Did the handling of the dossier objectively become slower or more incomplete afterwards? Were there concrete errors or unanswered questions in the record? Or was I remembering the experience as worse than the documentation supported? This distinction mattered to me. The workflow was not designed to produce a verdict or turn frustration into evidence after the fact. It was designed to challenge my assumptions and separate what I felt from what could actually be demonstrated. Where the documentation supported a complaint, we could point to the relevant chronology, delays, unanswered questions, or inconsistencies. Where the evidence was incomplete or ambiguous, that was noted too. The result was a more grounded account of the case: not “I know this was handled terribly,” but “these are the parts of my experience that are supported by the written record, these are the parts that remain uncertain, and this is where the timeline changed.” In simple terms, the workflow was: emails and dossier communications → chronology reconstruction → before-and-after comparison → review of delays, errors, and unresolved issues → evidence check against my complaints → a grounded account of what can and cannot be supported. What I liked about this workflow was that it used AI as a reality-checking tool rather than an agreement machine. It helped me test whether my criticism was actually anchored in the record before I relied on it in further communication. Step-by-step: 1. I gathered the relevant emails and dossier communications about my case. 2. I asked GPT to reconstruct the chronology and identify requests, replies, delays, unresolved issues, and changes in how the case was handled. 3. I compared the period before and after my feedback about a harmful aspect of the service and my request for reassignment, which was refused. 4. I examined whether the record showed that the process became slower or more incomplete, and whether it contained concrete errors or unanswered questions. 5. I separated points supported by the documentation from points that remained incomplete or ambiguous. 6. I used the resulting chronology and evidence check to create a grounded account of what my complaints could and could not demonstrate.

Build a Tiny HTML Research Logger Instead of Fighting a Spreadsheet Turn repeated research measurements into a simple phone-friendly interface instead of making participants wrestle with spreadsheets. Some research data is simple. Collecting it often isn't. Imagine recording pain, energy, mood and a few additional variables several times during a study. A spreadsheet can technically do this. But on a phone? Open the file, find the right row, locate the columns, enter values without accidentally changing something, save and close. That's a ridiculous amount of interface for a tiny measurement. If recording how you feel takes ten seconds mentally but two minutes administratively, the tool has become part of the research burden. So I asked: What is the smallest interface someone actually needs when logging an observation? My answer was a tiny HTML page that works on both phone and desktop. 1. Separate the interface from the dataset Participants shouldn't need to interact with rows, columns or database structures. They should see a few simple fields: Pain, Energy, Mood, Optional Note and Save. Behind the interface, each submission becomes a structured record containing the measurements, a timestamp and any optional context. The researcher gets organised data. The participant gets simple controls. 2. Define the research measures first Before asking AI to build anything, establish what you're measuring. Which variables matter? What does each scale mean? Which values are allowed? Should measurements remain comparable over time? These are research decisions, not interface-design decisions. AI can help implement your measurement system, but shouldn't quietly invent the methodology. 3. Design for repeated use A questionnaire completed once can tolerate some friction. A logger used several times a day cannot. Make controls large enough to tap comfortably. Use readable labels, vertical layouts and obvious actions. Avoid unnecessary navigation, tiny cells and repeated setup. Design for the phone first, then let the interface adapt to larger screens. And test the fifth entry, not just the first. Something that looks elegant during development can become irritating when you're tired, distracted or recording yet another observation. The ideal repeated action is almost boring. That's a compliment. 4. Automate the invisible work Participants shouldn't have to enter information the system already knows. A logger can automatically generate timestamps, record identifiers and technical metadata. Each submission should become one coherent record. Show a clear confirmation when saving succeeds and prevent accidental duplicates. Keep optional notes available without turning every measurement into a diary assignment. Don't make participants do the database's job. 5. Keep the interface neutral A research logger is a measurement instrument. Its colours, labels, ordering and controls shouldn't subtly suggest which answers are desirable. Likewise, the logger doesn't need to interpret someone's measurements or announce that their mood seems lower on Tuesdays. That's analysis, not collection. First gather observations reliably. Interpret them later using appropriate research methods. 6. Decide where the data lives A single HTML file can provide the interface without requiring a full application. But HTML alone doesn't provide persistent storage or synchronisation. Browser storage may work for a local prototype, although it has limitations. For research involving several devices, participants or longer periods, you'll need suitable storage and export options. A phone and laptop displaying the same interface don't automatically share observations. Keep the dataset consistent and exportable, for example as CSV. For sensitive information, include appropriate privacy and security safeguards. 7. Build only what's necessary It's tempting to expand a tiny logger into an entire platform. Dashboards! Charts! Profiles! Notifications! Accounts! Perhaps later. Start with Open → Measure → Save. Test the process repeatedly on phone and desktop. Improve whatever causes genuine friction. You can enlarge buttons or rearrange the layout without changing the study. But changing a measurement scale is a research-design decision, not a cosmetic update. The workflow Define the variables and scales → ask AI to build a responsive HTML logger → add automatic timestamps and structured records → choose suitable storage and export methods → test repeated logging → refine usability without changing the measurements. Why this works A spreadsheet is excellent at displaying a dataset. That doesn't make it the best place to create one. Researchers think in variables, records and analysis. Participants simply need to answer the question in front of them. Those shouldn't have to be the same interface. Sometimes the best research tool isn't a sophisticated platform. It's a tiny page that gets the spreadsheet out of the participant's way.

GeneTrust AI — Asistente Genético Virtual (AGV) es una plataforma tecnológica concebida bajo una arquitectura basada en evidencia (Evidence-First), asistida por IA y gobernada por humanos. Está diseñada para facilitar el acceso, la estructuración, la exploración, la clasificación, la priorización y la síntesis trazable de evidencia genética y biomédica. Su diseño busca prevenir riesgos críticos de la IA en biomedicina, como las alucinaciones, las referencias no resolubles, la pérdida de procedencia, el ocultamiento de contradicciones y la atribución indebida de autoridad clínica. Aplica operaciones aditivas y no destructivas: filtrar, clasificar o priorizar los datos nunca modifica ni reescribe la evidencia fuente original. Además, preserva la ambigüedad y los elementos no clasificables en lugar de forzar conclusiones artificiales. El stack tecnológico incluye React, TypeScript, Node.js y servicios en la nube. La plataforma integra un enfoque de múltiples proveedores y agentes de IA, con modelos generativos desacoplados, junto con una clasificación multidimensional de la evidencia mediante la abstracción de un Structured Decision Provider (SDP, Proveedor de Decisión Estructurada). Utiliza específicamente TypeSafe AI, con su modelo Jev, como proveedor de decisiones estructuradas bajo estrictas políticas de activación y gobernanza por dimensión. La IA y sus agentes asisten en la organización, exploración y síntesis de información compleja, pero no actúan como una autoridad diagnóstica ni determinan por sí mismos la verdad clínica. Sus salidas se manejan como inferencias computacionales controladas, separadas estrictamente de la evidencia fuente y sujetas a validación humana explícita. Step-by-step: 1. Accedo y estructuro la evidencia genética y biomédica dentro de una arquitectura basada en evidencia. 2. Exploro, clasifico y priorizo la información mediante operaciones aditivas y no destructivas, sin modificar ni reescribir la evidencia fuente original. 3. Mantengo la procedencia, las contradicciones, la ambigüedad y los elementos no clasificables, evitando forzar conclusiones artificiales. 4. Utilizo múltiples proveedores y agentes de IA, con modelos generativos desacoplados, para organizar, explorar y sintetizar la información compleja. 5. Aplico una clasificación multidimensional mediante la abstracción de un Structured Decision Provider (SDP), utilizando TypeSafe AI y su modelo Jev bajo políticas estrictas de activación y gobernanza por dimensión. 6. Trato las salidas de la IA como inferencias computacionales controladas, las separo de la evidencia fuente y requiero una validación humana explícita antes de utilizarlas.

A while ago, my dad told me he wanted to use AI to analyze World Cup matches. He had never coded before, and his AI experience was mostly limited to occasionally asking Gemini a question. I installed Claude Code for him and gave him a few prompting tips. He ended up building a full football analytics site himself and deploying it on Vercel so he could show it to his friends. Getting started with AI is easier than people assume. Sometimes, you just need a project you genuinely want to make. Now that the Premier League season has kicked off, he’s already reworking the site for it. Step-by-step: 1. I helped my dad choose a football analytics project he genuinely wanted to build for analyzing World Cup matches. 2. I installed Claude Code for him, since he had never coded before. 3. I gave him a few prompting tips and let him use AI to help build the site. 4. He built a full football analytics site himself. 5. He deployed the site on Vercel so he could show it to his friends. 6. After the Premier League season kicked off, he began reworking the site for the new competition.

My friend shot a short film and gave me his hard drive to help with post-production. It contained more than 400 clips, with no clear way to tell when each one had been shot. I asked Claude to review the metadata for every clip and group them by timestamp, so they were organized by shoot session instead of sitting in one large folder. Claude also built a spreadsheet listing each clip, its shoot session, the date, runtime, and file size. This saved my friend the hassle of reviewing every clip manually. Step-by-step: 1. I received my friend’s hard drive with more than 400 short-film clips. 2. I asked Claude to review the metadata for every clip. 3. I had Claude group the clips by timestamp and organize them by shoot session. 4. I had Claude create a spreadsheet with each clip’s shoot session, date, runtime, and file size. 5. My friend could avoid going through every clip manually.

AI image editors often change more than requested. Removing an object can alter the lighting, cleaning up a background can redraw a face, and fixing one detail can shift typography or proportions. That may be useful for creative transformation, but it is a problem when the goal is to change one thing and leave everything else alone. I now treat precision-editing prompts as preservation contracts. A precise edit needs two instructions: what must change and what must remain untouched. Failures happen when the requested change is clear but the boundaries are vague. For example, “Remove the grey area between the neck and ponytail” may also trigger a redrawn neck, shifted hair, or a smoothed silhouette. The result may look polished, but it is no longer faithful. Step-by-step: 1. I identify the smallest possible edit region. Instead of saying, “Clean up the portrait,” I specify, “Change only the grey area between the neck and ponytail to match the white background.” A narrow target limits unintended reinterpretation. 2. I name the protected elements instead of relying on “Leave everything else alone.” I identify faces, hands, text, positions, proportions, colors, silhouettes, and framing, and include: “Do not add, remove or redesign unrelated elements. Do not make compensatory changes elsewhere.” Otherwise, the AI may adjust shadows, symmetry, or composition to “balance” the edit. 3. I lock all text. Image models may rewrite text they were never asked to touch, so I specify: “Do not regenerate, correct, restyle or replace any text. Preserve spelling, capitalization, punctuation, line breaks, font appearance, size and placement exactly.” I protect labels, handwriting, and captions too. 4. I preserve geometry and framing. For a local correction, I specify: “Preserve all original proportions, positions and geometry outside the edit region. Keep the exact canvas size, aspect ratio and crop. Do not reframe or extend the image.” This is crucial for diagrams, collages, and layouts where spatial relationships matter. 5. I explain the background logic. For example: “Remove the object and reconstruct only the background naturally behind it, continuing the existing pattern without new texture or shadows.” White should stay white, patterns should continue, and shadows should follow the existing light. Removal is not redesign. 6. I ask the model to match the original style, including texture, grain, lighting, line quality, colors, and level of detail. Hand-drawn marks should not become glossy, and grainy photographs should not become plastic-smooth. I preserve imperfections such as crooked lines, collage edges, and photographic wear when they are meaningful. 7. I make fidelity the priority by stating: “This is a local corrective edit, not a reinterpretation or restyle. Prioritize fidelity to the source over beautification.” For risky features, I prohibit redrawn faces, altered text, new backgrounds, cropping, and unrelated corrections. If the target is ambiguous, I add: “If uncertain, preserve the original rather than editing additional areas.” 8. I make delicate changes separately. When there are multiple corrections, I edit one thing, inspect it, and then continue. More requests create more room for drift. 9. I verify what did not change by comparing the result with the source. I check the text, edges, faces, proportions, placement, crop, colors, and background, then ask two questions: Did the requested change happen? What else changed? The second question reveals hidden failures. I use this reusable prompt structure: Change: [specific requested change] Edit only: [exact region or element] Preserve exactly: [text, objects, positions, proportions, colors, framing, etc.] Do not: [likely unwanted changes] Style: Match the existing texture, lighting, grain, line quality and detail. Priority: Fidelity over beautification. If uncertain, preserve the source. For example, instead of writing, “Remove the grey bit under the hair,” I write: “Change only the grey area between the neck and ponytail to the same white as the surrounding background. Preserve the neck, chin, ponytail, silhouette, proportions, crop and all other colors. Do not redraw or beautify the face, hair or body. Do not alter anything outside the target region. Match the existing flat visual style.” The overall workflow is: define the smallest edit, identify protected content, preserve geometry, style, and background logic, forbid unrelated changes, prioritize fidelity, and compare the result against the source. The edit instruction tells the model where to go. The preservation constraints tell it where not to wander. The best corrective edit is not the most imaginative; it changes the target while everything else remains stubbornly itself.