Technical Concepts · Systems Vocabulary
A practical map of the AI, product engineering, and design engineering concepts I use to build production systems—from retrieval and runtime architecture to full-stack infrastructure, semantic interfaces, motion, and governed human control.
Each concept pairs a concise definition with a real project example showing how it was applied and what it enabled. Working Knowledge or Conceptual labels appear only where the portfolio does not show direct production application.
10 concepts
A system that can reason over a task, choose actions, call tools, use state, and iterate toward an outcome rather than only generate a single response.
The agent investigates inbound support requests with live tools and governed knowledge, then produces a draft while keeping the final outbound action under human control.
View Governed AI Email Agent case study →AI behavior organized around goals, tool use, state, iteration, and controlled autonomy. I use bounded agentic patterns rather than unrestricted autonomous execution.
A bounded reasoning loop lets the agent decide which tools to call and what evidence to gather before drafting, reducing manual investigation without allowing autonomous sending.
View Governed AI Email Agent case study →Lets a model invoke approved functions or APIs to retrieve live data or perform structured actions instead of guessing from model memory.
The agent calls account, subscription, entitlement, login, and product-help tools to ground its response in live system state instead of guessing.
View Governed AI Email Agent case study →Coordinates model calls, tools, state, validation, retries, and handoffs so a multi-step AI workflow behaves as one governed system.
A controlled tool-use loop coordinates investigation, evidence gathering, drafting, escalation, and approval as one governed workflow.
View Governed AI Email Agent case study →Places human judgment at defined decision points. I use HITL when an action is consequential, such as approving outbound communication before it is sent.
AI handles investigation and draft generation, while a human reviews, edits, sends, escalates, or closes the case before any customer-facing action occurs.
View Governed AI Email Agent case study →Constrains an agent with explicit tools, iteration limits, permissions, validation rules, and stop conditions so autonomy stays inspectable and controlled.
The tool-using loop is capped and constrained by allowed actions, preventing open-ended autonomous behavior while still enabling multi-step investigation.
View Governed AI Email Agent case study →Routes uncertain, sensitive, or unresolved cases to a human or higher-authority workflow instead of forcing the model to produce a confident-looking answer.
When evidence or confidence is insufficient, the workflow routes the case to a human instead of forcing the model to complete an uncertain answer.
View Governed AI Email Agent case study →Stores agent runs, tool calls, decisions, drafts, and outcomes so behavior can be inspected, debugged, evaluated, and audited after execution.
Agent runs, messages, drafts, tool activity, and audit history are persisted so decisions can be inspected and reconstructed after execution.
View Governed AI Email Agent case study →A hard system checkpoint that requires explicit human authorization before a consequential action can proceed.
Generated drafts cannot be sent automatically; explicit human approval separates AI reasoning from the irreversible customer-facing action.
View Governed AI Email Agent case study →A product and systems discipline focused on evidence, provenance, permissions, uncertainty, validation, and human control—not just model accuracy.
Canonical evidence, source lineage, claim verification, and explicit uncertainty states make recommendations inspectable rather than asking users to trust an opaque score.
View Career Agent case study →13 concepts
Retrieves relevant external knowledge at runtime and supplies it to the model before generation, grounding answers in current or controlled sources.
Relevant product and support knowledge is retrieved into runtime context before generation, improving grounding while keeping responses tied to governed source material.
View Governed AI Email Agent case study →The process of finding the most relevant information for a task before generation or decision-making. Retrieval can be keyword-based, semantic, filtered, or hybrid.
The runtime moved away from loading all available context and retrieves only relevant material for each request, reducing unnecessary context growth.
View Production AI Agent Runtime case study →Finds information by meaning rather than exact wording, allowing conceptually related evidence to surface even when the query uses different language.
Meaning-based retrieval connects job requirements to relevant career evidence even when the wording differs, improving evidence selection beyond literal keyword matching.
View Career Agent case study →Combines multiple retrieval signals—such as semantic similarity, deterministic filters, metadata, or keyword matching—to improve precision and recall.
Semantic and lexical retrieval are combined to select a smaller, higher-signal context set, addressing the scaling failure caused by a growing file corpus.
View Production AI Agent Runtime case study →Numeric representations of meaning used to compare semantic similarity between queries, documents, evidence, or requirements.
Semantic representations support meaning-based matching between requirements and evidence, helping surface relevant experience beyond exact phrase overlap.
View Career Agent case study →Searches embedding representations to retrieve semantically related content efficiently rather than relying only on exact text matches.
Vector similarity is used as part of semantic evidence retrieval so the system can locate conceptually related career facts efficiently.
View Career Agent case study →Structures information so AI systems can retrieve, trace, reason over, and safely reuse it. This includes canonical sources, metadata, relationships, and evidence boundaries.
Career evidence is organized into canonical, reusable knowledge with source lineage and claim boundaries, giving downstream analysis a more reliable foundation.
View Career Agent case study →Evaluates meaning and degree of fit rather than only exact keyword overlap—for example, assessing how strongly verified experience maps to a job requirement.
Requirements are evaluated by meaning and evidence strength—not simple keyword overlap—so the system can distinguish direct, transferable, partial, and missing matches.
View Career Agent case study →Preserves where a fact or claim came from so outputs can be traced back to canonical evidence rather than treated as unsupported model text.
Generated claims retain a path back to canonical evidence, making it possible to verify where a recommendation or resume statement came from.
View Career Agent case study →Requires recommendations or generated claims to be supported by retrieved, verified, or system-authoritative evidence.
Recommendations and generated resume claims are constrained to supported career evidence, reducing unsupported embellishment and making outputs easier to audit.
View Career Agent case study →Checks whether a generated statement is actually supported by available evidence before allowing it into a trusted output.
Before a claim is reused in tailored materials, the system checks it against canonical evidence and its source boundary to reduce overstatement.
View Career Agent case study →Uses uncertainty or insufficient evidence as a routing signal: high-confidence cases can proceed, while ambiguous cases are escalated or held for review.
Low-confidence or ambiguous requirements are surfaced for clarification instead of being silently converted into unsupported claims.
View Career Agent case study →Evaluates predictive systems while preventing future information from leaking into training or evaluation, preserving realistic out-of-sample testing.
Decision Lab evaluates frozen strategy behavior on later chronological market windows, helping test generalization without leaking future information into development.
View AI Financial Data Analytics case study →12 concepts
The architecture governing what happens while an AI system is executing: context assembly, model calls, tool use, state, retries, validation, escalation, and delivery.
The request lifecycle was re-architected after a 99-file context pipeline crossed its production time boundary, separating retrieval, context assembly, and model execution more deliberately.
View Production AI Agent Runtime case study →Designs what information enters an AI system’s working context, when it enters, how it is selected, and how it is structured for reliable execution.
Context is selected, structured, and assembled around the task instead of treating every available file as prompt input, improving scalability and signal quality.
View Production AI Agent Runtime case study →Chooses the smallest relevant subset of available information for a task instead of sending every available file or record to the model.
Only task-relevant context is selected from the larger corpus, reducing the amount of irrelevant material passed into the model.
View Production AI Agent Runtime case study →Builds the final model input from system rules, retrieved evidence, task state, conversation history, and structured data in a controlled order.
Retrieved evidence is organized into a deliberate runtime payload before the model call, making the prompt smaller and easier to reason about.
View Production AI Agent Runtime case study →The amount of input and output a model can process in one request. More context is not automatically better; relevance and assembly quality matter.
The production failure exposed why available context capacity is not the same as useful context; the redesign prioritizes relevant information rather than filling the window.
View Production AI Agent Runtime case study →Reduces unnecessary model input/output while preserving required evidence and behavior, improving latency, cost, and reliability.
Selective retrieval and tighter context assembly reduce unnecessary provider input, improving runtime efficiency without simply lowering model capability.
View Production AI Agent Runtime case study →Designs instructions, constraints, examples, and output expectations for a model. In production, I treat prompts as one layer of a larger system architecture.
System instructions define role, allowed behavior, evidence use, output constraints, and escalation rules so the model operates inside a predictable product workflow.
View Governed AI Email Agent case study →The highest-level model instruction layer used to define role, operating rules, boundaries, output behavior, and tool-use expectations.
The system prompt establishes tool-use rules, response boundaries, and human-approval requirements before the agent begins investigating a request.
View Governed AI Email Agent case study →Forces model responses into predictable machine-readable structures so downstream code can validate and safely use the result.
The model returns machine-readable fields instead of free-form prose alone, allowing the product to reliably drive UI state and downstream workflow.
View Governed AI Email Agent case study →Defines the exact structure, required fields, data types, and constraints expected from structured AI output or APIs.
Strict JSON Schema constrains model output to the fields the application expects, reducing parsing ambiguity between the LLM and product code.
View Governed AI Email Agent case study →Selects different models or reasoning tiers for different workloads based on complexity, cost, latency, or quality requirements.
Different analysis depths can be routed to different model tiers so fast screening and deeper evaluation do not require the same runtime cost.
View Career Agent case study →Weight-level model adaptation using training examples. I understand where it fits, but my current production AI systems primarily use prompting, tools, retrieval, structured context, and evaluation rather than weight-level fine-tuning.
In hands-on generative-AI experimentation, I trained an SDXL LoRA on curated visual examples to adapt model behavior at the weight level rather than relying only on prompt styling.
View AI Storytelling Animation case study →34 concepts
A defined interface that lets software systems request data or actions from one another. APIs connect the frontend, backend, AI providers, payments, and external services.
API is applied in the full-stack financial product to connect product behavior, data, and production infrastructure into a reliable end-to-end workflow.
View AI Financial Data Analytics case study →An HTTP-based API pattern using routes and methods such as GET, POST, PATCH, and DELETE to expose application data and operations.
REST API is applied in the full-stack financial product to connect product behavior, data, and production infrastructure into a reliable end-to-end workflow.
View AI Financial Data Analytics case study →A Python framework I use to build typed backend APIs, application services, AI orchestration endpoints, webhooks, and data workflows.
FastAPI is applied in the full-stack financial product to connect product behavior, data, and production infrastructure into a reliable end-to-end workflow.
View AI Financial Data Analytics case study →A component-based JavaScript library for building interactive user interfaces and reusable product behavior.
React is used to translate design intent into reusable, accessible production components and interaction behavior.
View Design Engineering + Motion case study →A React framework I use for production frontends, routing, rendering, application structure, and full-stack product interfaces.
Next.js is applied in the full-stack financial product to connect product behavior, data, and production infrastructure into a reliable end-to-end workflow.
View AI Financial Data Analytics case study →Adds static typing to JavaScript so component contracts, data models, and application behavior are easier to reason about and maintain.
TypeScript is used to translate design intent into reusable, accessible production components and interaction behavior.
View Design Engineering + Motion case study →The server-side layer that handles business logic, data access, authentication, integrations, AI execution, and secure operations behind the interface.
Backend is applied in the full-stack financial product to connect product behavior, data, and production infrastructure into a reliable end-to-end workflow.
View AI Financial Data Analytics case study →Persistent structured storage for application state, users, events, traces, transactions, evidence, analytics, and workflow history.
Database is applied in the full-stack financial product to connect product behavior, data, and production infrastructure into a reliable end-to-end workflow.
View AI Financial Data Analytics case study →A lightweight relational database used in several systems for durable application state, migrations, traces, and transactional records.
SQLite supports auditable growth infrastructure across attribution, revenue, commissions, authorization, and operational control.
View Affiliate & Creator Growth System case study →Verifies who a user is—for example, through login and session handling—before granting access to protected product areas.
Authentication is applied in the full-stack financial product to connect product behavior, data, and production infrastructure into a reliable end-to-end workflow.
View AI Financial Data Analytics case study →Determines what an authenticated user is allowed to see or do, including Admin-only actions and capability-based access.
Authorization supports the governed support-agent workflow, helping turn model behavior into a controlled, inspectable product process rather than an isolated chat response.
View Governed AI Email Agent case study →An event-driven HTTP callback that lets an external service push a change to the application, such as an inbound email or payment event.
Webhook supports the governed support-agent workflow, helping turn model behavior into a controlled, inspectable product process rather than an isolated chat response.
View Governed AI Email Agent case study →Connects subscriptions and payment events to product access, revenue state, attribution, commissions, and financial workflows.
Stripe Integration is applied in the full-stack financial product to connect product behavior, data, and production infrastructure into a reliable end-to-end workflow.
View AI Financial Data Analytics case study →The naming layer that maps domains and subdomains to infrastructure. I have configured domains, API subdomains, email-related DNS, and production routing.
DNS is applied in the full-stack financial product to connect product behavior, data, and production infrastructure into a reliable end-to-end workflow.
View AI Financial Data Analytics case study →Encrypts traffic between users and services. It is a baseline production requirement for authenticated apps, APIs, and payment-connected systems.
HTTPS / TLS is applied in the full-stack financial product to connect product behavior, data, and production infrastructure into a reliable end-to-end workflow.
View AI Financial Data Analytics case study →Sits in front of application services to route requests, terminate HTTPS, apply caching or security rules, and expose internal services safely.
Reverse Proxy is applied in the full-stack financial product to connect product behavior, data, and production infrastructure into a reliable end-to-end workflow.
View AI Financial Data Analytics case study →Stores reusable responses or assets closer to the requester to reduce repeated work, latency, and origin load.
Caching is applied in the full-stack financial product to connect product behavior, data, and production infrastructure into a reliable end-to-end workflow.
View AI Financial Data Analytics case study →Used for domain/DNS management, HTTPS, proxying, caching, and security around self-hosted product infrastructure.
Cloudflare is applied in the full-stack financial product to connect product behavior, data, and production infrastructure into a reliable end-to-end workflow.
View AI Financial Data Analytics case study →A standardized protocol for connecting AI clients to external tools, resources, and context through explicit contracts instead of one-off integrations.
RelayOS: implemented an official FastMCP stdio server plus a governed, transaction-aware MCP registry. An allowlisted read-only campaign-performance tool validates arguments, returns controlled data, and persists sanitized invocation audit events.
Figma workflow: connect Figma with Claude and Codex through MCP so AI development tools can consume design context through a shared protocol rather than separate custom integrations.
View RelayOS case study →Packages an application and its runtime dependencies into reproducible containers so services can build and run consistently across environments.
RelayOS uses production-oriented frontend and backend Docker images. I built the images, ran the stack, debugged a stale host-port collision, fixed a container healthcheck, and validated service health after restart.
View RelayOS case study →Defines and coordinates a multi-container application—including service dependencies, networks, ports, volumes, environment, and healthchecks—as one runtime topology.
RelayOS Compose coordinates Next.js, FastAPI, and PostgreSQL with health-dependent startup, migration/seed behavior, explicit ports, and persistent database storage. Compose config, builds, and restart validation passed.
View RelayOS case study →A production-grade relational database used for durable transactional state, relationships, constraints, and auditable application history.
RelayOS runs PostgreSQL 16 in Docker on host port 5440→5432. The database was validated healthy and accepting connections, with migration state and restart persistence verified.
View RelayOS case study →A Python SQL toolkit and ORM used to model relational domains, transactions, relationships, and database access in application code.
RelayOS uses SQLAlchemy 2.x declarative entities for WorkItems, agent runs, reports, assignments, handoffs, approvals, priorities, verification results, and activity events.
View RelayOS case study →A database migration tool for SQLAlchemy applications that versions schema changes and applies them predictably across environments.
RelayOS uses Alembic as the schema-evolution boundary. Final Docker/PostgreSQL validation confirmed the database at revision 0001 (head).
View RelayOS case study →Coordinates multiple specialized AI workers around shared goals, state, handoffs, and governance instead of asking one agent to own every capability.
RelayOS coordinates Lead, Social, and Design agents under Relay Manager. It persists AI→AI handoffs, supports AI→Human→AI resume, and separates specialist reasoning from deterministic routing and verification.
View RelayOS case study →Programmatic access to OpenAI models for structured reasoning, generation, tool-oriented workflows, and production AI application behavior.
RelayOS implements an OpenAI runtime using the official SDK and parsed Pydantic WorkReport schema, with provider model/request/usage fields persisted only when returned by the provider.
View RelayOS case study →Designing how application services, containers, databases, secrets, networking, observability, and delivery map onto AWS-managed infrastructure.
RelayOS was provisioned and validated on AWS using ECR, ECS Fargate behind ALB, private RDS PostgreSQL, Secrets Manager, CloudWatch, IAM, and GitHub OIDC. The system completed migration, deployment, smoke testing, persistence validation, redeployment, and controlled teardown.
View RelayOS case study →Defines cloud infrastructure as versioned, reviewable configuration so environments can be planned, reproduced, changed, and destroyed predictably.
RelayOS used Terraform for its AWS VPC, subnets, security groups, ALB, ECS/Fargate, ECR, RDS, Secrets Manager, CloudWatch, IAM/OIDC, and budget resources. Authenticated plans were reviewed before apply and the same stack was later destroyed with a residual-resource audit.
View RelayOS case study →Automates validation and controlled software delivery so code changes pass repeatable quality gates before deployment.
RelayOS uses GitHub Actions for backend tests, PostgreSQL/Alembic validation, frontend typecheck/build, Docker builds, Terraform/security checks, and a manually gated AWS deployment workflow that publishes immutable images, runs migration, updates ECS services, and verifies health.
View RelayOS case study →Uses short-lived federated identity and scoped permissions so deployment automation can access cloud resources without storing long-lived AWS access keys.
RelayOS GitHub Actions assumes a repository- and branch-restricted AWS deploy role through OIDC. Routine releases use temporary credentials and scoped deployment permissions, while human bootstrap and ECS runtime identities remain separate.
View RelayOS case study →Runs containerized services on managed compute, stores immutable images in a registry, and routes external traffic through a load balancer.
RelayOS published exact-SHA frontend and backend images to ECR, deployed them as ECS Fargate services behind ALB, used health-gated rollout behavior, and validated service stability and same-origin application routing.
View RelayOS case study →Provides managed relational database infrastructure with controlled networking, encryption, backup policy, and operational lifecycle.
RelayOS deployed PostgreSQL 16 on private RDS with TLS enforcement and backend-only network access. Application state survived an immutable service redeployment, and the database was later removed through the controlled teardown process.
View RelayOS case study →Combines runtime logs, readiness/liveness signals, deployment health, and verification checks so releases are judged by system behavior rather than deployment completion alone.
RelayOS sends ECS application logs to CloudWatch, separates liveness from database-backed readiness, verifies ALB target health, and requires migration and service health checks before a release is treated as successful.
View RelayOS case study →A shared specification for AI agents to safely discover, understand, and operate physical devices through standardized hardware interfaces. MHS is model-agnostic and can be accessed by agent harnesses through standard protocols such as MCP.
Anthropic opened MHS as a research preview with partners across science, robotics, electronics, and manufacturing. The preview is focused on interoperability, physical-world safety evaluations, and deployment best practices ahead of a planned open-source release.
View Anthropic research preview →11 concepts
The browser’s structured representation of a webpage. JavaScript and frameworks interact with the DOM to render and update interface behavior.
DOM — Document Object Model is used to translate design intent into reusable, accessible production components and interaction behavior.
View Design Engineering + Motion case study →Uses meaningful HTML structure and elements so interfaces remain understandable to browsers, assistive technology, developers, and automation.
Semantic DOM is used to translate design intent into reusable, accessible production components and interaction behavior.
View Design Engineering + Motion case study →A reusable interface unit whose rendered HTML structure, states, interactions, accessibility, and styling behave as a coherent component in the DOM.
DOM Component is used to translate design intent into reusable, accessible production components and interaction behavior.
View Design Engineering + Motion case study →Defines reusable interface primitives, variants, state ownership, composition rules, and boundaries so product UI scales without becoming inconsistent.
Component Architecture is used to translate design intent into reusable, accessible production components and interaction behavior.
View Design Engineering + Motion case study →A governed system of reusable components, tokens, patterns, interaction rules, documentation, and standards shared across product and brand experiences.
Design System was applied across the product and design system to improve consistency, responsive behavior, accessibility, and cross-team reuse.
View Island Dental Design System case study →Reusable named values for color, typography, spacing, radius, motion, and other design decisions that keep implementation consistent.
Design Tokens was applied across the product and design system to improve consistency, responsive behavior, accessibility, and cross-team reuse.
View Island Dental Design System case study →Interface behavior that adapts layout, hierarchy, controls, and content across screen sizes rather than simply shrinking a desktop design.
Responsive UI was applied across the product and design system to improve consistency, responsive behavior, accessibility, and cross-team reuse.
View Island Dental Design System case study →Designing and implementing interfaces so people with a wide range of abilities can perceive, navigate, understand, and operate them.
Accessibility was applied across the product and design system to improve consistency, responsive behavior, accessibility, and cross-team reuse.
View Island Dental Design System case study →Web Content Accessibility Guidelines: the core technical and design guidance I use for contrast, keyboard access, semantics, focus, and accessible interaction.
WCAG was applied across the product and design system to improve consistency, responsive behavior, accessibility, and cross-team reuse.
View Island Dental Design System case study →A U.S. civil-rights law that shapes accessibility requirements for digital experiences. In product work, I translate it into practical accessible design and implementation decisions.
ADA was applied across the product and design system to improve consistency, responsive behavior, accessibility, and cross-team reuse.
View Island Dental Design System case study →Defines how states, transitions, events, feedback, and motion work together as a system instead of as isolated visual effects.
Interaction Architecture is used to translate design intent into reusable, accessible production components and interaction behavior.
View Design Engineering + Motion case study →9 concepts
A JavaScript animation library I use for precisely controlled timelines, scroll behavior, transitions, and reusable motion systems.
GSAP coordinates multi-step motion timelines where sequencing and interruption matter, turning dense product-state changes into readable visual transitions.
View Design Engineering + Motion case study →A React motion library suited to component-level transitions, gestures, layout animation, and state-driven UI motion. My strongest production motion work currently uses GSAP.
Framer Motion handles reusable React component transitions and microinteractions, while GSAP is reserved for more orchestrated data-flow timelines and complex sequencing.
View Design Engineering + Motion case study →A reusable set of timing, easing, transition, state, and interaction rules that turns motion into a consistent product behavior layer.
Motion System is used to translate design intent into reusable, accessible production components and interaction behavior.
View Design Engineering + Motion case study →Models that generate new text, images, video, or other media. I use generative AI inside governed product and creative workflows rather than as a standalone novelty.
Generative AI supports a reusable creative system that keeps brand direction consistent while making multi-format production faster to scale.
View OnMed Brand System case study →Combines generative tools with reusable templates, brand constraints, human art direction, review, and production automation.
AI-Assisted Creative Workflow supports a reusable creative system that keeps brand direction consistent while making multi-format production faster to scale.
View OnMed Brand System case study →A parameter-efficient adaptation technique commonly used to specialize generative models. I have hands-on experience training LoRA for image-generation workflows on cloud GPU infrastructure.
I trained an SDXL LoRA on curated visual examples to create a reusable style adaptation, gaining hands-on experience with lightweight model fine-tuning for image generation.
View AI Storytelling Animation case study →Uses generative image models as one stage in a product or production workflow, with prompting, style control, selection, iteration, and human quality review.
Image Generation supports a productized generative-AI workflow that combines automation with human quality control and customer-facing output.
View AI Pet Portrait case study →Keeps concept, taste, composition, consistency, selection, and final quality decisions under human control even when AI accelerates production.
Human Art Direction supports a reusable creative system that keeps brand direction consistent while making multi-format production faster to scale.
View OnMed Brand System case study →Automates repeatable production steps while preserving brand constraints, review points, and human ownership of high-impact creative decisions.
Creative Automation supports a reusable creative system that keeps brand direction consistent while making multi-format production faster to scale.
View OnMed Brand System case study →These concepts are part of the systems I design and build—from AI agents and retrieval architecture to full-stack products, design engineering, and motion. Each example connects the technology to a real implementation and its role in the final product.