"The customer was the student in the study loop, not 'education' as a market. They needed three things in one sitting — know which topics past papers actually used, read those topics, and get a stuck question unstuck without waiting until evening. A chat box next to a PDF does the third badly if it is not grounded in their file, and it does the first dishonestly if the model invents a syllabus."

"The product was designed around a workflow I could watch — find material, understand it, resolve a doubt. PYQ ranking came from the observation that students treat every chapter as equal until an exam punishes them. The 35%, 50%, 2.5x, 3–10 min are user-testing results we reported for the project. If they want the protocol or sample size, I say I need to pull that — I do not invent it."

"A generic model does not know which PDF the student is holding. It can quote a formula from a different edition or a different board. That is a trust failure. Whole-book prompting also blows the latency I was targeting and still is not isolation. I wanted their file as the evidence set and PYQ as analytics over papers, not as the model predicting the exam."

"Cross-user retrieval. Mixing embeddings without user and document metadata would have answered one student's doubt from another student's notes. That can look smarter in a demo and still be the wrong product. I also refused to let the LLM own PYQ predictions — ranking observed topics is a different job from inventing the paper."

"That is a README mismatch on the current GitHub copy. The resume and giftedbooks.study are GiftedBooks — VR labs, PDF RAG, PYQ. AegisAI is a different personal-safety project. I would fix the README. I do not blend features to make one story sound larger."

"I would add a citation-facing eval so 'grounded' is measurable, not hoped. I would fix the README on day one. I would write down the user-testing protocol so 35% and 3–10 min have a denominator I can defend."

"Small retrieval set — I scope retrieval to user and document metadata, so the vector search is over a narrow partition, not all users' embeddings. Embedding is done once at upload time. At query time it is retrieval plus generation, and the generation call is the dominant cost. The p90 under 300ms is the API response time we measured."

"Analyst data-retrieval productivity on the resume. Before the chatbot, an operator who needed a number either learned SQL, waited for someone who knew SQL, or did not get the number. The chatbot collapsed that wait time. The 65% is how much faster data retrieval became across the product — I treat it as a workflow improvement, not a controlled A/B test. If they ask baseline hours, I say that methodology is something I need to lock — I will not invent a time-and-motion study."

"Trust is not 'the English sounded right.' Nest executes as the caller. RLS filters rows — it does not reject a legal SELECT. Missing GRANT is a permission error. App hasTableAccess is HTTP 403. The model proposes; the engine constrains. There is also a SELECT-only validator and a table allowlist before execution."

"Yes — data:null when rows existed, because a state-format mismatch broke the downstream parser. And MySQL-oriented SQL against PostgreSQL. Those are my Dive Deep / Are Right stories. A wrong empty state is a customer failure even when the warehouse is full."

"That correctness is the customer experience. A chatbot that returns an empty chart when data exists is worse than one that says 'I could not answer.' The customer lost trust in the tool even though the database was fine."

"Their recurring feedback exposed where users were struggling with analysis and reporting. That influenced us toward a more structured response flow and reusable rendering rather than treating the chatbot as a raw text interface. The ElementRenderer reuse decision came from observing that operators wanted consistent visual output across the chatbot and the report builder."

"I would explain what was technically needed, how it fit into the existing architecture, and what the timeline looked like. I did not say 'that is not possible' — I said 'here is what it takes and here is when we can have it.'"

"By impact on the actual workflow. If a request affected the primary data-retrieval path — chatbot, dashboards, reports — it took priority over cosmetic changes. I also prioritized based on how many users were affected versus how loud one user was."

"Because the product needed it. The operators could not wait for a staffing decision. The chatbot was half-built and the knowledge about it was walking out the door with the person who left. If I waited, we would have had to rebuild context from scratch."

"Understanding the assumptions baked into the prompt pipeline. The original developer had written the schema context assuming MySQL syntax — things like backtick quoting and LIMIT syntax that PostgreSQL handles differently. That was not obvious from reading the code; it only showed up when I looked at the actual generated SQL against the actual database."

"The FastAPI prompt service existed. The LangChain chain structure was already there. I changed the schema context to be PostgreSQL-aware, added validation on the generated SQL, rebuilt the response path from raw data dump to structured JSON with chart type and dimensions, wired execution through the RLS per-request transaction, and added logging at service boundaries so I could troubleshoot systematically. I did not rewrite the entire system from scratch."

"A few days of reading and tracing before I started making changes. I deliberately learned the unfamiliar pieces before changing them. I built a system map from the request path rather than learning every library in isolation."

"I would have added automated SQL validation tests from day one — a suite of known-good queries and known-bad queries that run against the actual database dialect. That would have caught the MySQL-oriented SQL much earlier."

"Because I treated the security boundary, the response format, and the prompt pipeline as my responsibility rather than assuming someone else would eventually fix them. The chatbot was not assigned to me. I saw a gap and filled it."

"I implemented the Nest integration and the DDL generator — rls.middleware.ts for per-request transaction, SET ROLE, set_config, fail-closed rls_no_access. policyManagement.service.ts for CREATE ROLE, GRANT SELECT, CREATE POLICY, ENABLE ROW LEVEL SECURITY. roleManagement.service.ts for CREATE ROLE db_role NOLOGIN and GRANT policyRole TO db_role. Query execution runs on req.dbTransaction. I did not hand-maintain warehouse SQL in this repo."

"Postgres does not inspect 'this WHERE asked for ORG_B therefore deny.' It checks GRANT — no SELECT means permission denied, that is Postgres RBAC. If SELECT is granted and RLS is enabled and the session is not a bypasser, it applies USING. Rows where USING is false are invisible. The statement succeeds. Empty result is not a reject. The caller's WHERE runs on already-visible rows — it cannot unhide a row that failed USING."

"If sales is in allowed modules and has the organizationId column: CREATE POLICY policy_organization_salesview_timestamp_sales_policy ON sales FOR SELECT TO that policy role USING true AND organizationId equals current_setting app.organizationId cast to uuid. The name is generated — policy underscore scope underscore sanitizedName underscore Date.now. I do not remember a production policy name. If sales is not in the module list, USING false."

"FORCE RLS means even the table owner cannot bypass. This generator emits ENABLE but not FORCE. Owner connections bypass. A proper finish also needs one real tenant column on every fact table and no owner reads of facts. If they open GitHub I will name which of those are gaps rather than guess."

"A Postgres role with NOLOGIN and no GRANTs on any fact table. If the middleware cannot find a valid db_role_name for the user, it SET ROLEs to rls_no_access. Any SELECT on a fact table immediately fails with permission denied. That is the fail-closed path — rather than falling back to the owner role and bypassing RLS."

"RBAC answers 'may this user call this API and touch this table.' RLS answers 'which rows are visible in Postgres for this session.' RBAC is Nest middleware — JWT roles, features, hasTableAccess. RLS is Postgres policies — USING clauses that filter rows based on session GUCs. They are complementary layers, not alternatives."

"No. I integrated the perception information into the navigation/costmap pipeline; I did not own the predictive planning implementation. Another team member owned the higher-level planning logic."

"Because I treated my module's integration with the rest of the system as my responsibility. I did not just get frames from the camera and throw them over the wall. I made sure the perception output was in the format and at the rate the navigation stack needed."

"Two rendering pipelines became one. The chatbot stopped being a special case with its own visualization logic and started speaking the same contract as the report builder. One renderer, one contract, two consumers."

"I built a prototype. Side-by-side comparison of the raw dump versus the structured render was enough. The data was the argument, not the preference. I did not argue theoretically — I showed a working example."

"If the chatbot's structured output did not match ElementRenderer's contract precisely, we would get rendering failures on the chatbot path without affecting the report builder. So I had to make sure the JSON contract was exact — chart type, data array dimensions, metric names."

"Because the existing abstraction already solved a large part of the problem. A second renderer would have increased code, testing and maintenance for the same visual outcome. Reuse made sense because the contracts were sufficiently compatible."

"Bar charts, line charts, tables, and other visualizations from the report builder's renderer. The key was that the chatbot's structured JSON contract matched the same format, so any chart type the renderer could draw, the chatbot could now return."

"A single-agent design can work for simple research, but the problem had different responsibilities and external tools. I separated the workflow so each stage could be observed and controlled independently. Cost control, debugging, and evaluation all require stage-level visibility."

"Planner, light search, clarifier, context builder, query generator, search fanout, aggregator, URL intelligence, scrape controller, cross-page reasoning, decision engine, synthesizer. Each is a Python function registered as a LangGraph node on the StateGraph."

"Because the consequence of a false negative is a worker on a factory floor without PPE. 73% mAP means roughly one in four detections is wrong or missing. For a safety system, that is not a model accuracy problem — it is a safety problem."

"More data — I expanded the training set to 15,000-plus images with diverse angles, lighting conditions, and PPE types. I also tuned augmentation parameters and training hyperparameters. The improvement was primarily data-driven, not architecture-driven. I did not switch to a different model architecture."

"I would add a human review loop for edge cases — the model flags, a human confirms. For safety-critical applications, model-plus-human is more reliable than model-only at any accuracy level. I would also explore more training data and potentially a larger model if the hardware budget allowed."

"Mean Average Precision — it measures detection accuracy across all classes by computing the area under the precision-recall curve for each class and averaging them. 73% mAP means the model's detection quality across all PPE classes averaged 73% when you consider both precision and recall."

"Containerized deployment with PostgreSQL logging for detected violations. Each camera feed runs inference at 24 FPS and logs violations with timestamps, camera ID, and detection confidence. Automated alerts trigger when a violation is detected."

"I saw queries failing against PostgreSQL and read the actual SQL. Backtick quoting was the first giveaway. Then I checked the prompt and saw it had no explicit dialect constraint. I also checked CloudWatch logs to see the actual SQL being sent to the database."

"The warehouse was PostgreSQL. The database was a decision made before I joined. Switching databases to match the chatbot's prompt would have been backwards — the prompt should match the database, not the other way around. Also, we chose PostgreSQL for Row-Level Security, which MySQL does not have."

"The database data existed, and the generated query itself showed the mismatch. That made the generation/prompt layer a more likely root cause than the data store. When I ran the corrected SQL manually against PostgreSQL, it returned the right data."

"No. It reduces specific invalid/unsafe output classes — MySQL syntax, non-SELECT queries, table access violations. Semantic correctness still needs schema context, prompt quality, evaluation and testing. Validation is a safety layer, not a complete semantic-correctness guarantee."

"Understanding state management across nodes. In a sequential chain, data flows linearly. In a graph, you have conditional routing and loops — the decision engine can send you back to search. Getting the state transitions right so the graph does not loop forever or miss data was the real learning curve."

"It thinks before expensive actions. URL intelligence scores and filters before scraping. Cross-page reasoning extracts facts before synthesis. The decision engine evaluates completeness before deciding to stop. A naive approach would scrape everything and feed it to the model — that is slow, expensive, and produces worse results."

"Caps on queries, URLs, scrape count, and character budgets for LLM context. The architecture document specifies cost control as a design principle — think before expensive actions. DeepQueryConfig contains configurable limits for search count, scrape count, max iterations, and character budgets."

"Persistent state. Right now state is per-run with a MemorySaver checkpoint in RAM. For production, I would want durable state so a crashed run can resume. I would also want better coverage metrics — how do I know the research actually covered the topic versus just finding a lot of pages?"

"A TypedDict that every node reads and writes. It contains the topic, plan, search results, URLs, scraped pages, knowledge blocks, facts, gaps, the decision, and the final answer. Operator reducers handle how state keys are merged — for example, lists get appended rather than replaced."

"It evaluates completeness by looking at the number of facts extracted, knowledge blocks from cross-page reasoning, the completeness score, and the gap analysis. If significant gaps remain and we have not hit the iteration cap, it sends the graph back to search or scrape. If coverage is sufficient or we hit caps, it proceeds to synthesis."

"ZED SDK documentation, ROS2 tutorials, and building small test programs. I started with getting depth data from the camera, then spatial mapping, then integrating with RViz for visualization. Incremental, not all at once."

"Understanding that a camera feed, depth data, coordinate frames, mapping, visualization and navigation are separate layers that only become useful when their interfaces agree. In web development, you have request-response. In robotics, you have continuous sensor streams that have to be synchronized."

"FPS is frames per second — how often the camera delivers a new image. Points per second is the spatial mapping throughput — how many 3D points the SDK processes to update the environment model. They are different metrics for different parts of the system."

"I do not have a specific count. I paired with newer team members as they joined. I will not invent a number."

"How to approach problems — read the error, trace the execution, check assumptions. Not specific technologies, but the debugging and problem-solving process."

"I would need to give a concrete example. I paired with team members who were new to the codebase and walked them through the debugging process. I do not have a named individual with a measurable outcome — I will not fabricate one."

"That they could independently handle a similar task next time without me sitting next to them. The goal was independence, not dependence."

"No. The useful response was to improve the workflow. The issue was coordination, so we reduced collision by separating work and merging deliberately."

"Because a logically correct JOIN could still return another organization's rows. I wanted the database to remain the final enforcement boundary rather than trusting generated SQL or an application WHERE clause. The WHERE clause is a convenience, not a security boundary."

"If the database session is operating under Organization A's RLS policy, the SQL's own WHERE clause cannot make rows invisible to the RLS policy become visible. USING runs first, then WHERE runs on already-visible rows."

"Prompt quality and validation reduce specific invalid output classes. They are not a guarantee that the model will never produce a query that touches data it should not. RLS is the guarantee — it operates at the database engine level regardless of what SQL gets generated."

"89% was the highest I could reach with the available data and training budget. A production system at 89% with automated alerts is more useful than a theoretical system at 95% that is never deployed. I would continue improving with more data."

"Before-and-after comparison of detected violations with and without the system running. If they want the exact population and time window, I say that methodology needs to be locked — I do not invent an N."

"Retrieval gaps — cases where the system retrieved irrelevant chunks and generated confident-sounding but wrong answers. Without tracing, those look like correct outputs. LangSmith lets me trace back from the output to the specific retrieval step that failed."

"For DeepQuery: facts extracted, pages scraped, filter yield, confidence score, source count, and report length. For the BRD processor: chunks retrieved, requirements extracted, test-case coverage. The per-run metrics are saved in JSON artifacts."

"Browser-based inference removes the environment setup step entirely — no local CUDA configuration, no dataset download, no dependency management. The 30% is a project-level estimate comparing the full 'download, configure, train, evaluate' workflow against 'open browser, select model, run.' If they want the exact measurement protocol, I say I need to lock that."

"I built it as a platform with a marketplace, not a single-use tool. The marketplace and community profiles are the growth mechanism. I did not ship a monetization layer — that is a next step."

"Because computer vision models need to be tested in context. A model that detects objects in a photo is different from a model that detects objects in a 3D environment with varying angles, lighting, and occlusion. The simulation lab lets developers test in context before deploying."

"At one hackathon, I had to choose between building a polished UI with fewer features or building more backend functionality with a rougher frontend. I chose the backend — because the judges were evaluating the product's capability, not its CSS. That was a reversible decision — I could have added polish if time allowed. It turned out to be the right call."

"Because in a 24-hour hackathon, two hours of planning is 8% of your total time. I plan enough to know the architecture, then I build. I learn faster from a broken prototype than from a perfect plan."

"Choosing GStreamer over alternatives on a tight timeline. If it had not worked, we would have needed to rebuild the entire video path close to competition. I mitigated by getting a working prototype quickly and testing under realistic conditions."

"Low-latency pipeline construction, good integration with Linux and embedded platforms, and the ability to handle multiple streams."

"The chatbot reads are much more frequent than writes to the underlying data. Cache-aside fits — you only cache what is actually queried. Write-through would cache everything including data nobody asks about."

"TTL-based. If the underlying data changes, the cache expires after the TTL and the next query hits the database. For a BI tool where data updates are periodic — Tally imports happen at intervals, not continuously — a TTL of a few minutes is a reasonable trade-off between freshness and latency."

"If the TTL expires and many users send the same query simultaneously, they all hit the database. For our scale this was not a problem. At larger scale, I would use a lock or a probabilistic early expiration to prevent thundering herd."

"For a BI tool, a few minutes of staleness is acceptable because the underlying data updates periodically through Tally imports, not in real-time. The TTL is set to a duration where staleness is tolerable for the business workflow."

"Because known KPI computations do not need probabilistic generation. A dashboard tile showing 'total sales this month' is a fixed query. Running it through an LLM adds latency, cost, and a failure mode with no benefit."

"Because SET ROLE plus USING plus fail-closed is significantly better than no isolation at all. The chatbot was generating SQL and executing it — without RLS, any generated query could see any organization's data. The shipped version constrains that. The gaps are real and I would close them, but shipping nothing while waiting for perfection is worse."

"Yes. The gaps exist because of incremental development — you ship the session binding and policy generator first, then add FORCE RLS and API guards. I did not hide the gaps."

"I would walk through what is shipped and what is not. I prefer that to hoping they do not look."

"I would have documented the concern, supported the chosen direction and implemented it well. The objective was the right engineering decision, not proving that my proposal had to win."

"I added logging at each step — after SQL execution, after formatting, before sending to the frontend. I compared the actual response payload against what the frontend parser expected. The mismatch was in the data structure, not the data content."

"Because the happy path worked — when data came back in the expected shape, everything was fine. The failure case was a specific response format that only occurred with certain query patterns. It was not a test gap; it was a specification gap — nobody had documented the exact format contract between the backend and the frontend parser."

"That would have hidden the symptom instead of fixing the source of the loss. The data existed. Masking the null with an error message would have told the user 'something went wrong' when in reality the system was working correctly up until the formatting step."

"I documented the exact response format contract so the expectation was explicit. I also added validation at the formatting step to catch format mismatches before they reached the frontend."

"By the gap analysis — are there subtopics from the original plan that have no supporting facts or knowledge blocks? If yes, the research has gaps. If the gaps are significant and we have not hit iteration caps, we continue. If the gaps are minor or we have hit caps, we synthesize with what we have."

"The system hits all its caps without achieving good coverage. In that case, the synthesizer produces the best report it can with incomplete data, and the confidence score reflects the incompleteness. The system does not pretend it has complete coverage."

"I would have asked what specific concern drove the decision, made sure I understood it, and then committed to making the text-dump path as good as possible. Disagreement is useful only until the decision is made."

"Not every disagreement was hierarchical. The important part was that I had a different technical view and supported it with evidence. Once we reached the decision, I was prepared to commit to it regardless of whether my option won."

"With a working prototype, not with a longer argument. The evidence was visual — the side-by-side comparison made the difference obvious."

"Pure vector search with semantic retrieval — simpler to build, fewer moving parts. The trade-off was that we would lose the structured requirement relationships. I chose hybrid because test-case generation needed those relationships."

"My clearest personal contributions were the chatbot stabilization, structured response and rendering work, RLS/RBAC integration, and performance work. The entire 40%/60% product-level outcome was broader team scope, so I would distinguish personal contribution from product-level metrics. That distinction increases credibility."

"The report builder uses deterministic SQL — the query is constructed from the report definition, not generated by a model. Compared to the previous workflow where operators had to build queries manually or wait for ad-hoc reports, the structured report builder reduced the time to generate a custom report by approximately 40%. The baseline is the previous manual workflow."

"That is the overall API performance across the deployed application on ECS, not a single endpoint measurement. It covers the dashboard, report, and chatbot API paths. The dashboard and report paths are deterministic SQL, so they are fast. The chatbot path includes LLM generation, so individual chatbot queries can be slower."

"The database. The PostgreSQL instance handles both the BI queries and the RLS policy execution. At 10x, I would add read replicas for the dashboard queries, increase the Redis cache coverage, and potentially move to a dedicated analytics database for the heavy aggregation queries. The ECS services themselves can scale horizontally behind the ALB."

"AWS CloudFront for CDN, Application Load Balancer routing to ECS services running Docker containers, PostgreSQL on RDS, Redis for caching, Route 53 for DNS with GoDaddy as the domain registrar, and CI/CD pipelines for automated deployment."

"The obvious risk was cross-tenant data exposure. The broader lesson was that making an AI system easier to query also makes a security mistake easier to scale, so the authorization boundary needed to be deterministic and outside the model."

"FastAPI handles the LLM pipeline — prompt construction, SQL generation, model interaction. NestJS is the execution and authentication layer — it owns the JWT, the RLS session, and the database connection. Separation means the LLM service cannot directly execute SQL and cannot bypass RLS. FastAPI proposes SQL; Nest is the only executor. FastAPI should not be publicly reachable."

"Row-Level Security. PostgreSQL's RLS with CREATE POLICY and USING clauses is a database-level mechanism that filters rows regardless of what SQL gets generated. This was critical because the chatbot writes SQL — the security boundary cannot be in the application WHERE clause. MySQL does not have RLS."

"A rendering component in the frontend that takes a structured JSON contract — chart type, data array, dimensions, metrics — and draws the visualization. Both the report builder and the chatbot use the same renderer, so any improvement to rendering benefits both products."

"The report builder produces deterministic SQL from a saved report definition — the same report always generates the same query. The chatbot generates SQL from natural language through the LLM — each question can produce different SQL. Both execute through the same RLS-protected transaction path."

"Admins manage policies, roles, and organizations through NestJS APIs. When an admin creates a policy, policyManagement.service.ts emits DDL — CREATE ROLE, GRANT SELECT on the relevant tables, CREATE POLICY with the USING condition, and ENABLE ROW LEVEL SECURITY. When a role is created, roleManagement.service.ts emits CREATE ROLE NOLOGIN and GRANT policy_role TO db_role. The middleware then SET ROLEs to the user's db_role on every request."

"The decision engine needs to loop back to search or scrape if coverage is insufficient. A sequential chain cannot loop. LangGraph's StateGraph with conditional edges supports iteration, and the shared DeepQueryState lets every node access the accumulated research."

"Caps on iterations, queries, URLs, and scrape count configured in DeepQueryConfig. The decision engine evaluates completeness against these caps. If the research is insufficient but we have hit caps, we proceed to synthesis with whatever we have."

"Each run saves to a folder: search_results with light and fanout JSON, urls with all, filtered, and visited URLs, scraped_pages with markdown content and index, knowledge with blocks, facts, and gaps, and output with final_report.md, sources.json, and metadata.json."

"There are two different meanings of 'graph' in this project. The LangGraph workflow graph is for orchestration — nodes like extract_text, generate_testcases. The Neo4j knowledge graph is for requirements — Document, Requirement, Entity nodes with DEPENDS_ON edges. They serve completely different purposes."

"Azure OpenAI embeddings producing 3072-dimensional vectors. The embedding service has batch processing, retry logic with tenacity, and a zero-vector fallback for failed embeddings."

"The test-case graph loads all requirements from Neo4j, retrieves relevant chunks from Azure AI Search using hybrid search, gathers graph context from Neo4j for requirement dependencies, then fans out with asyncio.gather to generate test cases in parallel across requirement groups."

"Left and right camera images go through stereo matching to produce disparity, then depth, then 3D points. The ZED SDK supports positional tracking using visual and inertial information from the camera's IMU, and spatial mapping that reconstructs the environment. This is stereo vision plus visual-inertial tracking in the SDK — I did not build a custom sensor fusion architecture."

"A grid representation where each cell has a cost representing how traversable or dangerous that area is. Obstacles have high cost, clear space has low cost, areas near obstacles have moderate cost. The planner evaluates candidate trajectories against the costmap — a slightly longer path with better clearance may have lower total cost."

"The ZED SDK itself can use visual and inertial information for positional tracking. Our work was centered on ZED-based perception and its integration with the rover software. I did not implement a custom sensor-fusion architecture outside of what the ZED SDK provides."

"GStreamer provides a dedicated media pipeline with encoding, transport, and rendering stages. Raw frame forwarding would require the application layer to manage all video transport mechanics. GStreamer handles the pipeline, and I configured it for low-latency operation on embedded hardware."

"Elastic Container Service — AWS's container orchestration service. It runs our Docker containers. We used ECS with Fargate, so we do not manage EC2 instances directly. ECS takes a task definition with the Docker image, CPU and memory requirements, and runs the containers. It handles container placement, scaling, and health checks."

"EKS is Elastic Kubernetes Service — AWS's managed Kubernetes. We do not use EKS. We use ECS, which is simpler for our use case. EKS gives you full Kubernetes with kubectl, Helm charts, pods, and services. ECS gives you container orchestration without Kubernetes complexity. For a BI application that does not need Kubernetes-specific features like custom controllers, service meshes, or complex rollout strategies, ECS is sufficient and has less operational overhead."

"ECS is simpler to operate for our workload. We have a web application, an API service, and background tasks — all standard HTTP workloads. EKS would give us Kubernetes flexibility we do not need and add operational complexity we do not want. If we needed multi-cloud portability, custom scheduling, or Kubernetes-ecosystem tools, EKS would make sense. We did not."

"Application Load Balancer — operates at HTTP layer 7. It routes incoming requests to the correct ECS service based on path rules, host headers, or other HTTP attributes. It handles SSL termination, health checks, and distributes traffic across healthy containers. In our setup, the ALB sits between CloudFront and ECS."

"AWS's CDN — Content Delivery Network. It caches static assets and API responses at edge locations globally so users get faster responses. For our React SPA, CloudFront serves the static JavaScript, CSS, and HTML from edge locations. For API requests, it can either pass through to the ALB or cache GET responses based on headers."

"AWS's DNS service. We use it to resolve our domain name to the CloudFront distribution. The domain is registered with GoDaddy, but DNS resolution is handled by Route 53 because it integrates natively with AWS services — we can point the domain directly to the CloudFront distribution."

"GoDaddy is where the domain is registered. Route 53 handles DNS resolution because it integrates with AWS. Route 53 points to CloudFront, which terminates SSL and routes to the ALB, which routes to ECS containers. It is a standard AWS web architecture."

"User's browser → GoDaddy domain → Route 53 DNS resolution → CloudFront edge (cache hit for static assets, pass-through for API) → ALB → ECS container running NestJS → PostgreSQL on RDS (through the RLS-bound transaction). For the chatbot: NestJS → FastAPI (private network) → LLM API → back to NestJS → execute SQL → return to frontend."

"Automated pipelines that build the Docker image, push to ECR (Elastic Container Registry), and update the ECS service with the new task definition. On each push, the pipeline runs — build, test, push image, deploy. No manual SSH to a server."

"Containerizing the NestJS and FastAPI services so they run identically in development and production. The Dockerfile specifies the runtime, dependencies, and startup command. ECS runs the Docker image. The container is the deployment unit."

"ECS can auto-scale based on CPU utilization, memory, or custom CloudWatch metrics. If load increases, ECS spins up more containers behind the ALB. For our BI workload, the scaling triggers are CPU-based — if average CPU across containers exceeds a threshold, scale out."

"Relational Database Service — managed PostgreSQL. AWS handles backups, patching, and failover. We use a single RDS instance for the BI data warehouse. At scale, I would add read replicas for dashboard queries."

"Azure's managed search service with both keyword (BM25) and semantic (vector) retrieval. We use it for hybrid search — combining keyword precision with semantic recall. The index stores BRD chunks with 3072-dimensional embeddings. On query, we retrieve using both methods and merge the results."

"A graph database where data is stored as nodes, relationships, and properties. We use it for the BRD knowledge graph — Document, Requirement, and Entity nodes with DEPENDS_ON edges. Queries use Cypher — like SQL for graphs. We use it because requirement dependencies are naturally a graph structure."

"LangChain is a framework for building LLM applications — chains, prompts, output parsers. LangGraph extends it with stateful graph orchestration — nodes, edges, conditional routing, shared state, and the ability to loop. I used LangChain at Ylogx for sequential chains. I use LangGraph at IQVIA because the pipelines need conditional routing and iteration."

"LangSmith is the observability and evaluation platform for LangChain/LangGraph applications. It traces every LLM call, retrieval step, and generation step. I use it for debugging, evaluating retrieval quality, and tracking pipeline metrics. It is the difference between 'the pipeline produced an output' and 'I can prove the output is correct.'"

"A web scraping service that returns clean markdown from web pages. DeepQuery uses it for both search (Firecrawl search API) and scraping (batch scrape with wave batches and content dedup using MD5 hashing)."

"Robot Operating System 2 — a framework for writing robot software. It provides inter-process communication through topics and services, coordinate frame management, and a standard way to integrate sensors, actuators, and processing nodes. We used it to connect the ZED camera, the video pipeline, the navigation stack, and the control system."

"A visualization tool for ROS2. It lets you visualize sensor data, 3D maps, robot models, and navigation paths in real-time. I used it to visualize the ZED 2's spatial mapping output and verify that the perception data was correct before feeding it to the navigation stack."

"A 3D physics simulator for robotics. It lets you test robot software in a simulated environment before deploying to real hardware. We used it for testing the navigation stack without needing the physical rover."

"Because the product depended on the chatbot and the person who understood it was leaving. Waiting for a staffing decision would have created a knowledge gap that was harder to close later. The risk of acting was lower than the risk of waiting."

"Understanding the assumptions in someone else's code. The prompt pipeline assumed MySQL syntax against a PostgreSQL database. That was not obvious from reading the code — it only surfaced when I looked at the actual generated SQL."

"When I could reproduce the system locally and trace a request from the frontend through NestJS to FastAPI to the LLM to SQL generation and back. I did not need to understand every library — I needed to understand the data flow."

"I would have asked what specific concern drove the decision, made sure I understood it, and then committed to making the text-dump path as good as possible. Disagreement is useful only until the decision is made."

"Yes — early in the RLS implementation, I was treating empty JSON responses as evidence that Postgres had rejected a query. That is wrong. An empty result from RLS means the rows were invisible under USING, not that Postgres rejected anything. Permission denied is a different path. I corrected my understanding and my explanation."

"I documented the exact response format contract and added validation at the formatting step to catch mismatches before they reached the frontend."

"That correctness at one layer does not guarantee correctness at the next. The query was right, the data was right, but the user still got nothing. I learned to trace the full path, not just verify individual components."

"The student using the product. They had a specific workflow — find material, understand it, resolve a doubt. I designed the product around that workflow, not around what was technically impressive."

"I did not evaluate every possible streaming framework exhaustively. I evaluated GStreamer against the main alternatives, decided it fit our constraints, and built the pipeline. If I had spent two more weeks evaluating, we would not have had a working video feed for the competition."

"Yes — if the renderer had forced unrelated requirements into one abstraction, I would have separated them. Reuse only made sense because the contracts were sufficiently compatible."

"Ship FORCE ROW LEVEL SECURITY. The generator emits ENABLE but not FORCE. Owner connections bypass RLS without FORCE. That is a real gap I would close."

"DeepQuery is a multi-stage research pipeline orchestrated by LangGraph. A natural language topic comes in, and the pipeline has eleven nodes: planner generates a research plan, light search does initial seed queries to ground the topic, clarifier optionally asks the human for scope refinement, context builder assembles what we know so far, query generator creates diverse search queries, search fanout dispatches queries across DuckDuckGo, Bing, and Firecrawl in parallel, aggregator deduplicates URLs, URL intelligence scores and filters URLs before we spend money scraping, scrape controller fetches pages in waves with content dedup using MD5 hashing, cross-page reasoning extracts facts and knowledge blocks by reasoning across multiple scraped pages, decision engine evaluates completeness and decides to loop back or proceed, and synthesizer generates the final markdown report with sources and confidence scores. Every node reads and writes to a shared DeepQueryState TypedDict. The decision engine's ability to loop back to search or scrape is why I used LangGraph instead of a sequential chain."

"It is a TypedDict with operator reducers. Key fields include topic, plan, search_results from light and fanout searches, all_urls, filtered_urls, visited_urls, scraped_pages, knowledge_blocks, facts, gaps, decision with action and reasoning, and answer which is the final report. Lists use operator.add as the reducer so multiple nodes can append without overwriting. The state is the shared memory for all eleven nodes."

"Before scraping, the URL intelligence node evaluates each URL for relevance, authority, and expected information density. It uses the LLM to score URLs against the research plan, filtering out low-value pages before we spend API credits on scraping. This is the 'think before expensive actions' principle — scraping is expensive, so we filter first."

"DeepQueryConfig has caps: max search queries, max URLs to scrape, max iterations for the decision engine, and character budgets for LLM context windows. If we hit any cap, the decision engine proceeds to synthesis with whatever we have. I also use wave-based scraping — scrape a batch, extract facts, check completeness, then decide whether to scrape more. This avoids scraping everything upfront."

"After scraping, the cross-page reasoning node takes all scraped content and reasons across pages to extract structured facts and knowledge blocks. A fact is a specific claim with a source. A knowledge block is a synthesized piece of understanding derived from multiple pages. This is different from just concatenating scraped text — it is extracting structured information before synthesis."

"The clarifier node can present the human with a clarification question based on the light search results. The human can refine the scope, and the pipeline continues with the refined topic. If human input is not available, the system proceeds with its best interpretation."

"Each run saves to a timestamped folder: search_results/ with light and fanout JSON, urls/ with all, filtered, and visited URL lists, scraped_pages/ with markdown content and an index, knowledge/ with blocks, facts, and gaps, and output/ with final_report.md, sources.json with confidence scores, and metadata.json with run statistics."

"Three things. First, persistent state — right now it uses MemorySaver in RAM, so a crashed run cannot resume. I would use a durable checkpoint backend. Second, streaming — right now the user waits until synthesis is complete. I would stream intermediate results so the user can see progress. Third, coverage metrics — I need a better way to measure whether the research actually covered the topic versus just finding many pages."

"Those are single-turn search-and-answer. DeepQuery is iterative — it plans, searches, reasons across sources, evaluates completeness, and decides to search again or stop. The decision engine can loop multiple times. It also saves full artifacts for every run so you can audit the research process, not just the final answer."

"The BRD processor has two LangGraph state machines. The ingestion graph has eight nodes: load the document as PDF or DOCX, extract text, chunk it, generate embeddings with Azure OpenAI at 3072 dimensions, index chunks into Azure AI Search, extract structured requirements with an LLM, build a Neo4j knowledge graph with Document, Requirement, and Entity nodes and DEPENDS_ON edges, and save metadata. The test-case generation graph has five nodes: load requirements from Neo4j, retrieve relevant chunks from Azure AI Search using hybrid retrieval, gather graph context for requirement dependencies from Neo4j, fan out with asyncio.gather to generate test cases in parallel across requirement groups, and aggregate results."

"Vector search finds semantically similar text. It does not understand that Requirement A depends on Requirement B, or that a change to B should trigger re-testing of A. The graph stores these structural relationships — Document nodes at the top, Requirement nodes with IDs, titles, types, and priorities, Entity nodes for domain concepts, and DEPENDS_ON edges between requirements. When generating test cases, the graph context tells the LLM which requirements are related, not just which text is similar."

"Three node types: Document with properties like title and source, Requirement with id, title, description, type, priority, and Entity with name and type. Two relationship types: HAS_REQUIREMENT from Document to Requirement, and DEPENDS_ON between Requirements. The schema is created during ingestion using Cypher queries."

"Azure AI Search supports three retrieval modes: keyword search using BM25, vector search using embeddings, and semantic ranking that re-ranks results using a transformer model. Hybrid combines keyword and vector — you get both keyword precision for exact terms and semantic recall for conceptually similar content. I use the hybrid mode for BRD chunk retrieval."

"Azure OpenAI's text-embedding-3-large model produces 3072-dimensional vectors. The embedding service has batch processing to handle large documents, retry logic with the tenacity library for transient API failures, and a zero-vector fallback for any chunks that fail to embed. The embeddings are stored in the Azure AI Search index alongside the text content."

"The test-case generation graph loads all requirements, retrieves relevant chunks and graph context, then uses asyncio.gather to generate test cases for multiple requirement groups in parallel. Each group gets its own LLM call with the requirement, its dependencies from the graph, and relevant text chunks from the vector index. This is significantly faster than generating test cases sequentially."

"It showed retrieval gaps — cases where the system retrieved irrelevant chunks and generated confident-sounding but wrong test cases. Without tracing, those look like correct outputs. LangSmith lets me trace from the final test case back to the specific retrieval step, the specific chunks retrieved, and the specific LLM prompt that generated it. I can diagnose whether the failure was in retrieval or generation."

"Two completely different meanings of 'graph.' The LangGraph workflow graph is for orchestration — it controls the sequence of operations: load, extract, chunk, embed, index, build graph, save. The Neo4j knowledge graph is for data — it stores the structured relationships between documents, requirements, and entities. LangGraph tells the pipeline what to do next. Neo4j stores what the pipeline has learned about the document."