--- title: "Forward deployed engineering" description: "A personal proof of work for forward deployed engineering: the proposed RELAY customer-operations workflow, the architecture, and the decisions behind it." canonical: "https://www.ayushrai.site/pow/fde/" last-updated: "2026-10-19" --- # Forward deployed engineering Source: https://www.ayushrai.site/pow/fde/ Markdown: https://www.ayushrai.site/pow/fde.md A personal proof of work for forward deployed engineering: the proposed RELAY customer-operations workflow, the architecture, and the decisions behind it. I build systems that solve real operational problems. From ambiguous problem statements to working software: I investigate workflows, connect systems, build AI-powered solutions, and validate the result. In progress. Personal engineering project. RELAY is a proposed demonstration on this page, not a product deployed for a customer. The company, accounts, and scores below are a proposed demonstration scenario. ## Engineering starts with the problem, not the technology. ### Understand the workflow first Read how the work happens today: who looks, which system they open, what they write down, and where the handoff breaks. ### Name the operational friction The useful problem is the delay, the missed signal, or the decision that cannot be reconstructed. A new screen is not the problem statement. ### Inspect data and system boundaries Find which system owns the account, the ticket, the usage event, and the permission to act. The design follows those boundaries. ### Choose the simplest architecture that meets the requirement Add a service, a model, or a queue when the requirement needs it. Until then, keep the path short enough to test. ### Integrate systems The result has to meet the CRM, the support tool, and the analytics product where the teams already work. ### Use AI where it changes the work Use a model to summarize retrieved evidence and to draft a recommendation. Use rules where the output must be repeatable. ### Keep outputs inspectable and actions controllable A person can see the records behind a claim. A consequential write waits for an explicit approval. ### Validate the result Sending the request is not the same as the account changing. Check the outcome, and record what was true. ## RELAY — Customer operations intelligence Personal proof-of-work project. A B2B SaaS company, in this scenario, has customer information spread across its CRM, support system, product analytics, and internal communication tools. Teams lack one place to see a deteriorating account, the evidence, and the next action. Investigation is manual, signals are missed, and decisions lack a shared trail. 1. Fragmented customer data. Account facts sit in the CRM, the support system, product analytics, and internal chat. 2. Manual investigation. Someone opens each tool, copies notes, and tries to reconstruct the week. 3. Delayed identification. A deteriorating account is noticed when a person happens to look, not when the signals line up. 4. Inconsistent decisions. Two reviewers can see different slices and choose different next steps, with no shared evidence. 5. Untracked follow-up. The message, the CRM edit, or the decision not to act leaves no single trail. ## From fragmented signals to an actionable decision. Deterministic stages apply rules. AI-assisted stages may draft text from retrieved evidence and must fail closed. The human gate is an approval, not a model. ### 1. Ingest events (Deterministic) Enters: A payload from a source adapter: CRM, support, product analytics, or an internal event stream. Happens: The adapter checks the payload shape and attaches a source name and a source event id. Leaves: A validated raw event, or a rejection. Can fail: A timeout, or a payload the adapter does not recognize. Verified by: The raw event is stored once. The same source event id does not create a second raw event. ### 2. Normalize records (Deterministic) Enters: A validated raw event. Happens: Fields map into a shared account, person, and event schema. Unmapped fields stay attached as source extras. Leaves: A normalized event with a pointer back to the raw payload. Can fail: A required field is missing or has the wrong type. Verified by: The normalized record traces back to the raw payload. Invalid events stay out of the domain model. ### 3. Detect operational signals (Deterministic) Enters: Normalized events for one account. Happens: Rules look for repeated severe tickets, a usage drop, a missing owner, an overdue invoice, and similar conditions. Leaves: Signal records that name the rule and the event ids that triggered it. Can fail: The rule's input is missing, or two sources disagree. Verified by: Each signal cites event ids. A missing input is recorded as missing. ### 4. Calculate transparent risk scores (Deterministic) Enters: The signal records for one account. Happens: Each triggered rule adds its points. The score is the sum. A model does not set or adjust it. Leaves: A score and the rule lines that produced it. Can fail: A signal that does not belong to a known rule. Verified by: Adding the stored point lines again reproduces the score. ### 5. Investigate the underlying evidence (AI-assisted) Enters: The account, its signals, and the records those signals cite. Happens: Retrieval is a query. A model may summarize only those records. If the model is unavailable, the evidence list still stands. Leaves: An evidence packet, and a summary only when the model output passes validation. Can fail: The summary cites a record that was not retrieved, or the provider returns nothing usable. Verified by: A person can open every cited record. A rejected summary is withheld. ### 6. Generate recommendations (AI-assisted) Enters: The evidence packet and the score breakdown. Happens: A model may draft a next step that cites the packet. A template can restate the rule result with no model. Uncited claims are discarded. Leaves: A recommendation marked as a draft or a template, plus the evidence ids it used. Can fail: The draft cites nothing, cites unknown ids, or the provider times out. Verified by: The visible recommendation cites only ids in the packet. Otherwise no recommendation is shown. ### 7. Request human approval (Human gate) Enters: A recommendation and one concrete proposed action. Happens: The action waits. A person approves or rejects it. The system does not approve itself. Leaves: A decision that names the person and the time, or a proposal that is still waiting. Can fail: The proposal is incomplete, or the person rejects it. Verified by: A waiting or rejected proposal has no successful execution. ### 8. Execute an authorized action (Deterministic) Enters: An approved action and the idempotency key for that approval. Happens: The workflow calls the target system and stores the adapter result. Leaves: An execution record: succeeded, failed, or retrying. Can fail: The target times out, returns an error, or the approval was already used. Verified by: The response or the timeout is on the execution record. Sending the request is not treated as success. ### 9. Verify the result (Deterministic) Enters: An execution record. Happens: A follow-up read checks the condition the action was meant to change, when the target allows a read. Leaves: Confirmed, not confirmed, or not checkable. Can fail: The read times out, or the target state does not match the intended change. Verified by: The write result and the later read are stored as separate facts. ### 10. Record the audit trail (Deterministic) Enters: The event ids, score breakdown, recommendation, approval, execution, and verification. Happens: Those identifiers and decisions are appended to an audit history. Leaves: An audit entry a person can read later. Can fail: A required identifier is missing, so the entry is stored as incomplete. Verified by: From the entry, a person can walk back to the evidence, the rules, the approver, and the execution result. ## Simulated product preview The accounts are predefined. No model is called and no workflow is executed. ### Northline Analytics (Synthetic · mid-market) Score: 90 (sum of the rule points). - Repeated severe tickets: 25 points. Add 25 when two or more severity-1 tickets open in 14 days. Three severity-1 tickets opened in 14 days. - Usage drop: 20 points. Add 20 when weekly active users fall by more than half against the prior 4-week median. Weekly active users moved from 40 to 11. - No current owner: 30 points. Add 30 when the CRM champion is inactive and no successor is set. The champion is marked inactive. The owner field is empty. - Overdue invoice: 15 points. Add 15 when an invoice is more than 14 days past due. One invoice is 18 days past due. Sample recommendation: Sample text, written for this preview: ask the account's sales owner to confirm a successor and to review the open billing-export tickets before any customer message is sent. Proposed action: Draft an internal handoff. Create an internal note that lists the three tickets, the usage drop, the empty owner, and the open invoice. Do not email the customer from this step. A person has to approve the internal note before it is written to the CRM. ### Harbor & Co (Synthetic · mid-market) Score: 20 (sum of the rule points). - Usage steady: 0 points. Add 0 when weekly active users stay within 10 percent of the prior median. Weekly active users stayed at 28 against a median of 27. - Single severe ticket: 10 points. Add 10 for one open severity-2 ticket and no severity-1 ticket. One severity-2 ticket is open. - Conflicting owner notes: 10 points. Add 10 when two sources disagree about the account owner. Do not pick a winner. CRM names Priya Shah. The support thread names an empty owner. Sample recommendation: Sample text, written for this preview: do not contact the customer while the owner notes disagree. Ask an operator to resolve the owner, then re-read the severity-2 ticket. Proposed action: Hold external contact. Leave the customer message unsent. Open an internal task to reconcile the owner field. A person has to confirm the hold. The preview does not create the task. ### Fieldnote (Synthetic · startup) Score: 0 (sum of the rule points). - Usage steady: 0 points. Add 0 when weekly active users stay within 10 percent of the prior median. Weekly active users are 16 against a median of 15. - No severe tickets: 0 points. Add 0 when no severity-1 or severity-2 ticket is open. No severe tickets are open. - Owner present: 0 points. Add 0 when the CRM owner and champion are both active. Owner and champion are active. Sample recommendation: Sample text, written for this preview: no customer action. The rules that ran did not add points. Proposed action: No external action. Record that the account was reviewed and that no write was proposed. Nothing is waiting for approval. ## Proposed system architecture Documented as a proposal. The UI, API, domain logic, database, model provider, and external systems are separate boundaries. ### Data sources Systems that already hold the customer record. RELAY would read them through adapters. Components: CRM, Support platform, Product analytics, Internal event streams. Responsibility: Remain the systems of record for their own objects. RELAY does not replace them. Interfaces: Each source is reached only through an adapter. The rest of the system sees normalized events. Boundary: External systems. Credentials and tenant permissions stay in the adapter configuration. ### Ingestion The door for events. It validates, normalizes, and refuses duplicates. Components: Source adapters, Validation, Event normalization, Idempotency. Responsibility: Turn source payloads into normalized events exactly once. Interfaces: Adapters implement a shared ingest contract. Valid events are written for the domain layer to read. Boundary: Sits between external systems and domain logic. It does not score and it does not act. ### Domain logic Account identity, signals, the score, and the evidence attached to both. Components: Account resolution, Signal detection, Deterministic risk scoring, Evidence aggregation. Responsibility: Decide which account an event belongs to, which rules fire, and which records support them. Interfaces: Reads normalized events and writes account, signal, and score records. Returns an evidence packet to the application and to the AI module. Boundary: Pure domain rules. No model call and no external write. ### AI services Optional language help on top of retrieved evidence. Components: Investigation summaries, Evidence-grounded recommendations, Structured output validation. Responsibility: Draft a summary and a recommendation that cite retrieved records, then reject output that fails the schema or the citations. Interfaces: Receives an evidence packet. Returns structured text or a typed failure. The domain score is an input, not a field the model may overwrite. Boundary: A provider sits behind this module. The application shows a summary only after validation. ### Workflow engine Turns an approved proposal into one external write, and records the outcome. Components: Action generation, Approval gates, Execution, Retry and failure handling. Responsibility: Hold an action until a person approves it, execute it once, and retry without double-applying. Interfaces: Reads an approved action. Calls an execution adapter. Writes an execution record the audit trail can cite. Boundary: The only path to an external write. The UI cannot call a source system around it. ### Persistence The proposed system of record for RELAY's own facts. Components: PostgreSQL, Domain records, Execution records, Audit history. Responsibility: Keep accounts, signals, scores, approvals, executions, and audit entries across restarts. Interfaces: Domain, workflow, and audit modules read and write through the application database. The browser preview does not. Boundary: One database for this phase of the design. Caches, if added later, do not replace these records. ### Application The surfaces an operator would use. This page previews them. Components: Account explorer, Investigation interface, Approval queue, Operations dashboard. Responsibility: Show evidence, scores, and proposals, and collect an approval. It does not score or execute on its own. Interfaces: Would call an application API for accounts, investigations, and approvals. Phase 1 implements the investigation with predefined data in the browser. Boundary: UI. It is not the domain layer and it is not the database. ### Observability How an operator would see that the pipeline is unhealthy. Components: Processing errors, Execution outcomes, Integration health, Auditability. Responsibility: Surface rejected events, failed executions, adapter timeouts, and the audit trail. Interfaces: Reads processing and execution records. It does not invent a success to clear an alert. Boundary: A read model over the records the other layers write. ## Why the system is designed this way. ### Deterministic scoring versus LLM-generated scores Problem: A risk number that changes when the prompt changes cannot be explained after an incident. Alternatives: - Ask a model for a score. - Let a model adjust a rule score. - Add points from versioned rules and keep the model away from the number. Selected: Rules add the points. A model may discuss the evidence. It does not author the score. Reason: The same signals must produce the same score, and an operator can see which rule fired. Trade-off: Rules miss situations nobody encoded. A model might notice a new pattern and still be wrong. What would change it: Revisit if a review set shows the rules disagree with how operators judge risk, and a model score can be reproduced. No such review exists. ### Human approval versus unrestricted autonomous execution Problem: The interesting actions write to another system or contact a customer. Alternatives: - Execute when the score crosses a threshold. - Require approval for every action, including reads. - Require approval for every external write, and let investigation stay read-only. Selected: Every external write waits for an explicit human approval. Reading evidence does not. Reason: The system proposes. A person accepts the consequence. Trade-off: Approval adds delay, and a noisy queue can become a rubber stamp. What would change it: A specific action could use a narrower gate once it is shown to be reversible and low-consequence. RELAY has no customer operating history to show that. ### Idempotent event processing versus naive ingestion Problem: Source systems retry. A second delivery of the same ticket must not double the score. Alternatives: - Insert every payload. - Hide duplicates in the UI after storing them. - Store a source plus source event id, and ignore a repeat. Selected: An event is identified by its source and source event id. A repeat does not create a second domain effect. Reason: The score should follow the world, not the number of webhook attempts. Trade-off: A source that reuses ids for genuinely new events would drop the later event. The adapter has to match that source's id contract. What would change it: If a source cannot provide a stable id, give that adapter a documented fallback key and a replay test. ### Simulated adapters versus real integrations during development Problem: This proof of work does not have a customer's CRM, support tenant, or analytics sandbox. Alternatives: - Wait to build anything until a live tenant exists. - Call live APIs with personal tokens and treat the result as a demo. - Define the adapter contract and return fixed payloads from a simulated adapter. Selected: Simulated adapters that return the payloads this page already shows. The contract is what a real adapter would implement. Reason: Domain behavior can be inspected without implying a customer system is connected. Trade-off: A fixture will not reveal that tenant's rate limits, schema drift, or permission errors. What would change it: Replace a simulated adapter when a sandbox, a written data contract, and a replay test exist. ### Evidence-grounded recommendations versus unsupported model output Problem: A fluent next step that cites nothing cannot be checked. Alternatives: - Let the model write from the account name. - Retrieve records and require the draft to cite them. - Use templates only, with no model. Selected: Recommendations cite retrieved records. A template may restate a rule. Uncited claims are rejected. Reason: The operator's job is to check the claim against the evidence. Trade-off: The draft can only know what retrieval returned. A missed record becomes a missed recommendation. What would change it: If citations pass and operators still find the prose misleading, prefer the template for that action. ### A modular application versus premature microservices Problem: The diagram has several layers. They do not yet have independent traffic, teams, or failure budgets. Alternatives: - Deploy a service per stage now. - One application with module boundaries and one database. - One script with no internal boundaries. Selected: One application. Ingestion, domain, AI, and workflow are modules behind interfaces, with PostgreSQL as the store. Reason: The boundaries are for clarity and later extraction. Extra deployables would add network failures first. Trade-off: A module that later needs its own scale or release cycle has to be extracted. The interfaces should allow that. What would change it: Extract a service when one module has a scaling, security, or release constraint the single application cannot meet. ### Persistent records versus transient in-memory state Problem: An approval and an audit row have to survive a restart, or they are not operational records. Alternatives: - Keep the demo in memory and call it the product. - Persist domain, execution, and audit records in PostgreSQL. - Persist only the final audit line and recompute everything else. Selected: PostgreSQL for domain records, execution records, and audit history. This page's preview lives in the browser and is not that database. Reason: A later reader has to be able to ask what was approved and what the adapter returned. Trade-off: A database needs migrations, backups, and a local setup that this phase does not include. What would change it: A cache or a queue may sit beside the database for throughput. It does not replace the approved-action record. ### Auditability versus opaque automated decisions Problem: If the only stored fact is that a message was sent, the reason is gone. Alternatives: - Log the final action only. - Store evidence ids, the score breakdown, the recommendation, the approver, and the execution result. - Store raw prompts and full customer payloads indefinitely. Selected: Store the evidence identifiers, the rule breakdown, the recommendation text, the approval, and the execution result. Reason: An operator should be able to read the trail without opening a hidden prompt. Trade-off: A tighter record omits some debugging detail. A wider record copies customer data into a second system. What would change it: If an incident cannot be explained from the stored fields, add the missing field on purpose. ## Failure is part of the design. The behaviors below are the ones I would build. They are not running mechanisms. ### Duplicate events The source and source event id match an event already stored. The duplicate is acknowledged and not applied again. The score stays as it was, and the processing log notes the duplicate. ### Invalid input Validation rejects the payload. It is not normalized and it does not enter scoring. The rejection is a processing error, with the source id when one was present. ### Unknown accounts An event that cannot be resolved to an account is parked as unresolved. It does not create a score and it does not propose an action. ### Unavailable model providers Scoring and evidence retrieval still run. The summary and the drafted recommendation are marked unavailable. No action is proposed from an empty model response. A template may restate the rule result. ### Integration timeouts The adapter records the timeout and does not report success. The workflow step stays retryable. A timeout is not an approval. ### Failed workflow execution The execution record stores the failure. The action stays incomplete. A retry uses the same idempotency key so a write that actually landed is not sent twice. ### Repeated execution requests A second request for the same approved action returns the existing execution record. It does not send a second message or a second CRM write. ### Rejected approvals The proposal closes as rejected. Nothing is executed. The person and the time are stored with the rejection. The score is unchanged. ### Missing or conflicting evidence The score uses only rules whose inputs are present. Missing inputs are shown as missing. Conflicting records are shown together, and a recommendation that would have to pick one silently is withheld. ## How I would take this from a customer problem to a working deployment. This is my working sequence for a real engagement. It is not a claim that the engagement has happened. ### 1. Discovery Sit with the workflow and the business objective. Write down what a good week looks like for the operator. Deliverables: - Workflow map - Problem statement - List of decisions the system must not make alone ### 2. Mapping Name the people, the systems, the fields, and the constraints, including what we are not allowed to write. Deliverables: - Stakeholder map - System inventory - Data-source notes ### 3. Design Turn the workflow into requirements, interfaces, and checks that can fail a build. Deliverables: - Architecture notes - Data contracts - Acceptance tests ### 4. Integration Connect one source at a time and compare the normalized records with the source. Deliverables: - Integration specification - Fixture or sandbox sample - Validation notes ### 5. Implementation Build the smallest workflow that completes one useful loop, including the unhappy path for that loop. Deliverables: - Working slice - Architecture decision records for the choices that were expensive to reverse ### 6. Evaluation Check correctness, failure behavior, and whether an operator can explain the score. Deliverables: - Validation report - Failure-case notes - Usability notes from the operator ### 7. Deployment Configure the environment, run the system against the agreed checks, and watch the first real events. Deliverables: - Deployment checklist - Configuration notes - Rollback note ### 8. Handoff Leave the limits, the operating steps, and the next increment in writing. Deliverables: - Operational runbook - Known limitations - Next-step list ## Technical roadmap ### Phase 1. Website and interactive architecture preview (Implemented) This page: the narrative, the diagrams, and a simulated investigation with predefined accounts. Implemented in this repository as a client-side page. It is not a separate RELAY service. ### Phase 2. Working application and persistent data model (Planned) An application shell backed by PostgreSQL tables for accounts, signals, approvals, and audit rows. Planned. The preview on this page does not persist. ### Phase 3. Event ingestion, normalization, signals, and scoring (Planned) Adapters, validation, idempotency, signal rules, and the deterministic score. Planned. The preview sums points that are written into the page. ### Phase 4. AI-assisted investigations and recommendations (Planned) Summaries and recommendations that cite retrieved evidence and fail closed when validation fails. Planned. This page does not call a model. ### Phase 5. Human approvals, workflow execution, and auditability (Planned) An approval queue, idempotent execution, and an audit history. Planned. The approval control in the preview stays in the browser. ### Phase 6. Real integration adapters, deployment hardening, and operational validation (Planned) Sandbox adapters, failure drills, and a deployment checklist run against a real environment. Planned. No customer environment is connected. ## Related work ### RevenueRoles Technical revenue roles are scattered across many employer job boards under inconsistent titles, so people looking for them have to read every description to know what the job is. What it demonstrates here: Employer-system connectors, a classification pipeline, and a live homepage. The product record says saved jobs and applications are not built, and that no user or revenue numbers are published. - On this site: /products/revenueroles - Live: https://revenueroles.in - GitHub: https://github.com/ayushrai-hub/RevenueRoles ### Revenue Intelligence Engine Synthetic-data GTM pipeline that scores 42 fictional companies against an ICP on a deterministic 100-point rubric, researches the top accounts, and holds export behind human approval. No real leads, CRM writes, or outbound. What it demonstrates here: A deterministic rubric over fictional companies, with export held for a person. The project record says there are no real leads, CRM writes, or outbound. - On this site: /projects#revenue-intelligence-engine - Recorded demo: https://cashmaker-two.vercel.app - GitHub: https://github.com/ayushrai-hub/REVENUE-INTELLIGENCE-ENGINE ### AGENYRA In a crowded AI ecosystem, people struggle to discover, understand, evaluate, and actually reach the product that fits a task. A list of websites does not answer that. What it demonstrates here: A public site and waitlist. The product record keeps structured search experimental and says intent-aware discovery is not a public capability. - On this site: /products/agenyra - Live: https://agenyra.space/ - GitHub: https://github.com/ayushrai-hub/AGENYRA_product ### SpiderWeb Turns your own LinkedIn data export into a searchable map of your network: people, companies, roles, and conversations, deduplicated, with a graph view. Runs locally; no production deployment. What it demonstrates here: A local map of a LinkedIn data export, deduplicated. The project record says there is no production deployment. - On this site: /projects#spiderweb - GitHub: https://github.com/ayushrai-hub/SpiderWeb ### MedVoice Pharmaceutical wholesalers bill through a handoff from the person picking stock to the person typing the invoice. Look-alike medicines, pack sizes, and tax make that handoff a high-consequence transaction. What it demonstrates here: Speech proposes an order line. Deterministic rules handle identity, tax, and posting, and a person confirms risky matches. The product record says there is no public demo and no warehouse deployment. - On this site: /products/medvoice - GitHub: https://github.com/ayushrai-hub/MedVoiceERP ### The Open Framework Civil-society organizations, donors, talent, and institutions lack a shared, consent-aware way to discover one another and to tell which organizational claims have been checked. What it demonstrates here: A front-end prototype for a coordination concept. The product record places verification, consent, and the institutional backend in the design-goal column. - On this site: /products/the-open-framework - Live: https://the-open-frameworks.vercel.app/ - GitHub: https://github.com/ayushrai-hub/the-open-framework ### Personal portfolio (this site lineage) Vite + React + TypeScript portfolio with Tailwind, Framer Motion, and serverless contact, evolving into a structured content layer. What it demonstrates here: This website. Its pages, Markdown, search, and public API read one content layer. - On this site: /projects#personal-portfolio - Recorded demo: https://www.ayushrai.site - GitHub: https://github.com/ayushrai-hub/ayush-work ## Closing I like working where the problem is still messy, the systems are fragmented, and the solution needs to be engineered. - GitHub: https://github.com/ayushrai-hub - LinkedIn: https://www.linkedin.com/in/ayushrai02/ - Portfolio: https://www.ayushrai.site - RELAY has no public repository yet. _Unverified award metrics are omitted. Wording matches the public site._