Microsoft Certified: Azure Administrator Associate (AZ-104)
Microsoft / Associate certification
Azure identity and governanceStorage and computeVirtual networkingMonitoring and resource administration
PROJECT AND CREDENTIAL RECORDS
The work, the evidence, and what I learned.
A compact index for hiring managers and technical reviewers. Open any project to inspect scope, outcomes, lessons, evidence, and the current documentation gaps.
01 / CREDENTIALS
Certification index
Exact credential names, ordered by relevance to my current cloud, DevSecOps, and AI systems work.
AI Engineering for Developers Associate
DataCamp / Associate certification
LLM application designRAGVector retrievalPrompt engineeringProduction evaluation
Machine Learning Foundations Professional Certificate
Anaconda / Professional certificate
Supervised and unsupervised learningData preparationModel evaluationPython ML tooling
Docker Foundations Professional Certificate
Docker, Inc. / Professional certificate
Container imagesMulti-stage buildsComposeVolumesContainer security and lifecycle
GitHub Foundations (GH-900)
Microsoft / Certification
Git and GitHub workflowsGitHub ActionsRepository securityCollaboration and administration
Microsoft Applied Skills: Azure Administration
Microsoft / Applied Skills credential
Hands-on Azure administrationResource configurationIdentityNetworking and monitoring
Cambridge C1 Advanced English
Cambridge English / Language qualification
Professional English communicationTechnical writingAdvanced reading and comprehension
Used across published technical work
02 / PROJECTS
Expandable project index
Published case studies come first. Recovery-stage records state what is verified and what still needs to be recovered instead of presenting incomplete work as finished.
01 PromptTriage RAG-powered prompt engineering platform backed by production-prompt research, structured evaluations, and documented cloud experiments.
Primary outcome
Turned prompt quality from an intuition-led workflow into a measurable research and product system, including a +13.9% relative instruction-following result over generic prompts.
+13.9% relative instruction-following improvement PromptTriage versus a generic prompt in the scoped Study D IFEval comparison.
+12.3% relative downstream quality lift PromptTriage versus no system prompt in the scoped Study C v2 comparison.
1,080 structured format evaluations The format study used a separate three-model jury with no overlap with the tested models.
28K+ prompt research corpus Corpus used across the wider production-prompt research program.
What I built
- A Next.js product surface with Supabase authentication, Stripe subscription flows, FastAPI retrieval services, and Pinecone vector search.
- A research program spanning a 28K+ prompt corpus, 1,080 structured format evaluations, retrieval studies, model comparisons, and LLM-as-judge review.
- A PR-gated container delivery path that built frontend and backend images, ran CI and security checks, pushed approved images to Azure Container Registry, and deployed them to Azure Container Apps through managed identity.
- Deployment experiments across Azure Container Apps and Google Cloud Run while Supabase and Pinecone remained external managed data services.
What I learned
- Simple retrieval can outperform more complex agentic RAG when the evaluation target and corpus are tightly scoped.
- Benchmark design, retry behavior, and inference implementation can dominate cloud cost.
- Research claims become more useful when architecture, failures, costs, and incomplete evidence are published together.
Evidence available
- Public product and repository
- Template-backed case study with architecture visual
- Azure ML job metadata and EUR 178.12 cost evidence
- Published benchmark diagrams and research articles
- Marketing-oriented V2 product walkthrough in the Research-chart GitHub release
02 ViperMesh Unified workspace for 3D artists and engineers with a proprietary Blender agent, browser 3D engine, and integrated neural 3D tools.
Primary outcome
The ViperMesh Blender harness beat the Anthropic x Blender MCP baseline on speed, token usage, and unbiased LLM-judge visual evaluation.
6 of 7 live benchmark speed wins Both harnesses used the same OpenAI GPT 5.5 High acting model.
2.534x mean live-task speedup Across seven comparable live and agentic Blender tasks.
-90.91% local acting-agent token usage Measured on one comparable Scandinavian entryway token-window pair.
+8.19 pts neutral LLM visual-evaluation lift 83.333 versus 75.143 over seven live render pairs.
What I built
- An initial Electron client and custom ReAct-style reasoning loop for a local Blender-connected vertical AI product, followed by LangChain and LangGraph orchestration as the system matured.
- A progression from system prompts, few-shot examples, and curated execute_code scripts to a deterministic Blender addon with roughly 130 task-focused tools.
- A rewritten addon connection and MCP layer that give agents explicit scene operations, relevant context, and validated parameters instead of repeatedly generating Blender Python from scratch.
- A browser-based 3D workspace for viewing, interacting with, and processing models through an end-to-end product workflow.
- An open-source persistent MCP server and Blender addon while keeping the wider product and proprietary tools private.
What I learned
- Tool boundaries and artifact-aware feedback can improve agent performance without changing model weights.
- Spatial tasks need direct inspection evidence; a text-only agent completion claim is not a reliable quality gate.
- A narrower deterministic tool surface can reduce token use while improving task accuracy and execution time.
- Most early generation failures were harness and evaluation failures rather than proof that the underlying model needed weight changes.
Evidence available
- Seven comparable live Blender benchmarks using the same OpenAI GPT 5.5 High model
- Unbiased LLM-judge visual evaluation
- Interactive benchmark charts and downloadable report
- Public Blender connector source
03 Harneloop Framework for building self-evolving agent harnesses through portable harness units, trace-backed diagnosis, and evidence-gated promotion.
Primary outcome
Created a structured way for agents to diagnose failed outputs, generate harness candidates, and keep only changes that improve repeatable tests.
What I built
- Portable harness units that preserve task context, artifacts, traces, evaluators, and candidate history in isolated environments.
- A loop that traces failures, proposes harness changes, reruns tests, and promotes candidates only when evidence improves.
- The evolution workflow used to improve ViperMesh Blender-agent spatial reasoning and tool use.
What I learned
- Generic self-reflection is not enough when an agent cannot inspect or understand the artifact it produced.
- The harness around a model can be a more efficient improvement surface than fine-tuning for narrow operational tasks.
- Candidate isolation and evidence-gated promotion prevent one improvement attempt from silently degrading the working baseline.
Evidence available
- Public framework repository
- Public product site
- Technical case study
- Applied ViperMesh benchmark evidence
04 n8n Automation Atlas Curated and synthetically generated n8n workflow corpus for direct import, machine-learning tasks, and retrieval-grounded workflow generation.
Primary outcome
Published 36,985 import-ready workflows and a 131,648-row ML-oriented dataset across two Hugging Face releases.
What I built
- Python and JavaScript generation pipelines that produce full n8n JSON workflow structures with semantic labels.
- A searchable public explorer plus two dataset releases for different operational and ML workloads.
- Corrective RAG experiments to test whether extra retrieval correction improved workflow generation.
What I learned
- Full importable workflow structure is more useful for small models than isolated snippets with no canvas context.
- Synthetic scale does not replace schema validation, deduplication, or retrieval-quality measurement.
- Corrective RAG added complexity without a measured performance gain in the tested setup.
Evidence available
- Public repository and workflow explorer
- Two Hugging Face datasets
- Published corpus and dataset counts
- Technical case study
05 nullstate-cli Local-first purple-team CLI created for the AMD x lablab.ai hackathon to test Terraform against emulated cloud targets with self-hosted model reasoning and deterministic remediation.
Primary outcome
Live-validated the AWS LocalStack path from exploit evidence to deterministic Terraform remediation and a blocked post-fix replay while keeping the model endpoint private.
48h original hackathon build window The project has continued beyond the submission as an open-source alpha.
104.45 tok/s AWS red-agent output speed Gemma 4 26B final AWS run telemetry on the self-hosted MI300X endpoint.
160.94 tok/s AWS blue-agent output speed Gemma 4 26B final AWS remediation explanation telemetry.
Blocked post-remediation AWS replay The public S3 exploit path succeeded before and was blocked after the deterministic fix.
What I built
- A Python CLI that reads Terraform, starts local sandbox targets, detects supported exposures, runs red/blue reasoning, applies deterministic fixes, repeats validation, and emits evidence artifacts.
- Self-hosted open-source models through ROCm and vLLM on an AMD Instinct MI300X, reached through a private SSH tunnel and OpenAI-compatible endpoints.
- LocalStack AWS and Azure-style container environments used as controlled targets instead of attacking production cloud resources.
- A professional DevSecOps repository with PR checks, Ruff, mypy, tests, CodeQL, dependency review, security documentation, evidence manifests, and release media.
What I learned
- Security recommendations are more useful when tied to reproducible attack evidence, deterministic remediation, and a replay of the same attack path.
- Model reasoning can improve adversarial explanations without becoming the source of truth for the security verdict.
- An SSH-tunneled vLLM endpoint keeps GPU inference private while preserving a standard API contract for local tooling.
- Hackathon delivery still benefits from branch protection, release evidence, threat modeling, and explicit limits on what is not yet live-validated.
Evidence available
- Public source repository and work-in-progress portfolio case study
- AMD MI300X, ROCm, vLLM, Docker, PR, and CLI screenshots
- Live-validated AWS LocalStack run artifacts with attack blocked after remediation
- Public demo video and AMD hackathon submission summary PDF
Evidence still needed
- Complete template-backed case-study narrative and final visual selection
- Live Azure Blob validation, currently blocked by LocalStack Azure Emulator entitlement
- Independent baseline tools beyond the deterministic generic IaC-only comparison
06 Private Secure AI Automation Platform Private automation platform that evolved from a self-hosted n8n instance on a Google Cloud VM into an Azure Container Apps environment for n8n and OpenClaw.
Primary outcome
Migrated persistent n8n data and configuration from a VM deployment into Azure Files-backed container volumes, built a remotely operable private platform, then converted a cloud-credit overrun and emergency teardown into concrete cost-control and recovery lessons.
EUR 1,175.21 subscription-level accumulated cost Screenshot scope covers December 2025 through May 2026 across all services, not this project alone.
EUR 747.78 Azure Container Apps service total The retained screenshot does not itemize this total by ViperMesh, PromptTriage, and private-platform workload.
3 private data and network controls Private endpoints, private DNS, and VNet segmentation were recovered from the topology.
What I built
- An initial self-hosted n8n instance running directly on a Google Cloud virtual machine before the service was containerized.
- A migration path that moved n8n data and configuration into Azure Files in a Storage Account, pulled a fresh n8n container image into Azure Container Apps, mounted the retained files as volumes, and rebuilt the supporting database services.
- Container Apps for n8n and OpenClaw with Tailscale connectivity; Termius on a mobile device provided private remote shell access for debugging containers while away from the workstation.
- Resource-group-scoped automation access for the OpenClaw container so it could inspect and operate sibling services through prompted workflows.
- A shared n8n workflow-data mount available to both services, allowing OpenClaw to create, trigger, and reuse n8n workflows instead of duplicating automation logic.
- A private PostgreSQL Flexible Server, Azure Files storage, Premium Azure Container Registry, VNet subnets, private endpoints, and private DNS zones.
- Custom Azure Workbooks for daily cost allocation by resource and service, alongside persistent data paths built around managed database storage and mounted volumes.
What I learned
- Cloud credits are not a cost-control system; budgets, alerts, quotas, and automated shutdown rules must exist before experimental services scale.
- Cost dashboards explain spend after it happens, but they do not replace a budget with thresholds and action rules.
- An automation agent capable of operating sibling resources needs narrowly scoped identity, immutable audit evidence, and a tested recovery boundary.
- Emergency deletion without a tested export and rebuild path turns an infrastructure incident into an evidence-recovery project.
- Private networking, DNS, identity, storage, and container lifecycle need to be documented as one platform rather than as isolated resources.
- Migrating a stateful service from a VM to containers requires an explicit data, configuration, database, volume, validation, and rollback plan rather than only deploying a new image.
- The planned rebuild will apply these lessons to an on-premises Kubernetes server with reproducible manifests and recovery procedures.
Evidence available
- Public blog note confirming the earlier Google Cloud-hosted n8n instance
- Azure billing and activity metadata
- Recovered resource topology and deletion sequence
- Confirmed Container Apps, PostgreSQL, ACR, Azure Files, VNet, private endpoint, and private DNS resources
- Subscription-level cost screenshot covering December 2025 through May 2026
Evidence still needed
- Original container definitions and sanitized environment-variable templates
- Tailscale configuration, Termius connection evidence, and routing policy
- OpenClaw managed-identity role assignments and n8n integration configuration
- Application logs, workbook exports, backup policy, alert rules, and recovery runbook
- Network diagram or exported templates saved on the other computer
07 ViperMesh Azure GPU Inference Pilot Containerized open-source Hunyuan3D workloads for GPU-backed shape and texture generation during ViperMesh private-alpha validation.
Primary outcome
Established an end-to-end path from neural 3D generation to ViperMesh ingestion and browser-engine inspection, then documented why scale-to-zero configuration alone was not an adequate GPU cost control.
EUR 676.67 verified Container Apps cost Actual cost queried at the gpumodels resource-group scope for 1 April through 1 July 2026.
EUR 563.56 Paint API / A100 lane vipermesh-paint-api, including EUR 480.62 billed directly to the Standard NC A100 v4 GPU meter.
EUR 113.11 Shape API / T4 lane vipermesh-shape-api, including EUR 71.67 billed directly to the Standard NC T4 v3 GPU meter.
EUR 552.29 direct GPU-meter cost Combined A100 v4 and T4 v3 GPU meters, or 81.6% of the two Container Apps total.
PR to ACR gated container delivery CI, lint, security checks, image build, registry checks, and managed-identity deployment.
What I built
- Separate Hunyuan Shape and Hunyuan Paint HTTP services with stable generation, texturing, and health contracts.
- Migrated the model services from unreliable RunPod scale-to-zero endpoints into modified Azure-compatible images, using A100 GPUs for the primary workloads and T4 GPUs for smaller models.
- A PR-gated delivery path: local Docker development, CI/lint/security checks, approved GitHub merge, image build, ACR push and scanning, then managed-identity pull and Container Apps reprovisioning.
- Azure Container Apps deployment automation for T4 and A100 workload profiles, managed identity, ACR pulls, scaling, and bearer-token secrets.
- Startup, readiness, and liveness probes plus low-VRAM and paint-resolution runtime controls.
- Alert rules and email notifications for container downtime and selected application error signals, plus detailed cost-allocation monitoring.
- Private-alpha tests that moved generated 3D assets through the ViperMesh application and its custom browser 3D engine.
What I learned
- GPU services need workload-specific memory lanes and startup thresholds rather than one generic container profile.
- Model-worker containers and normal HTTP services require different deployment contracts and should not be interchanged.
- End-to-end product validation must inspect the generated asset in the consuming engine, not stop when the model endpoint returns a file.
- The configured scale-to-zero policy did not prevent a large observed Azure Container Apps bill; budgets and itemized cost exports must be validation gates, not later monitoring tasks.
Evidence available
- Azure deployment scripts with no embedded credentials
- GitHub Actions variable and secret-name template
- Hunyuan Shape and Paint Docker/API source
- T4/A100 quota and workload reference
- Azure Cost Management resource-group query showing EUR 676.67 of Container Apps cost for the gpumodels pilot
- Resource and meter allocation: vipermesh-paint-api on A100 v4 and vipermesh-shape-api on T4 v3
Evidence still needed
- Historical Container Apps run logs and GPU utilization
- Private-alpha output captures from the other computer
08 Open-source contributions and mentorship Direct fixes and technical mentorship across Prowler, Graphiti, and Matplotlib, with outcomes linked to upstream pull requests.
Primary outcome
Shipped a merged OCI auditing fix in Prowler, helped a student land a Matplotlib documentation fix, and traced a Graphiti provider-compatibility defect that was later covered by the upstream factory refactor.
1 merged direct upstream fix Prowler OCI audit-client home-region correction.
1 merged mentored contribution Matplotlib gallery thumbnail fix authored by the student contributor.
1 superseded validated compatibility proposal Graphiti maintainers closed the PR after equivalent non-OpenAI routing landed upstream.
What I built
- Prowler PR #10347 fixed a 404 in the OCI audit-retention check by creating the Audit client in the tenancy home region and adding regression tests.
- Graphiti PR #1339 traced non-OpenAI compatible endpoints to an OpenAI Responses API mismatch, proposed generic-client routing, and received independent Ollama validation before being superseded by the merged factory refactor.
- Mentored a second-year computer-science student through Matplotlib PR #31308, which added a missing Sphinx Gallery thumbnail for the multipage PDF example and was merged upstream.
What I learned
- An upstream fix starts with a reproducible failure, a narrow root cause, focused tests, and maintainers being able to review the change in their own architecture.
- A useful contribution can influence a later upstream implementation even when the original pull request is not merged verbatim.
- Mentoring a contribution means teaching issue selection, repository conventions, implementation discipline, and review follow-through rather than taking over the authorship.
Evidence available
- Merged Prowler PR #10347
- Merged Matplotlib PR #31308 authored by the mentored contributor
- Graphiti PR #1339 and maintainer note confirming it was superseded by the merged factory refactor
- LinkedIn recommendation from the mentored contributor
09 Hackathon engineering and mentorship Technical delivery across StoryForge and the 8x Mobile starter, including team mentoring, agent observability, CI/security posture, and judge-facing documentation.
Primary outcome
Helped a five-person StoryForge team ship a voice-driven Gemini storybook pipeline to Cloud Run while mentoring an early-career developer on observable LLM application engineering.
5 people StoryForge hackathon team Project-owner documented team composition: technical development plus marketing roles.
122 StoryForge backend tests Models, safety, state, observability, and API coverage recorded in the project log.
8 of 9 end-to-end checks Recorded at the verified text-to-agent-to-tools-to-page pipeline milestone.
What I built
- StoryForge voice-to-story pipeline using React, FastAPI, Google ADK, Gemini Live, Imagen, TTS, Firebase, WebSockets, PDF export, and Cloud Run.
- In-process tracing, metrics, health endpoints, safety counters, nested pipeline spans, authentication, and a 122-test backend suite for StoryForge.
- A production-minded 8x Mobile hackathon starter with architecture, case-study, security, release, CI, CodeQL, dependency review, and AI-agent contribution guidance.
What I learned
- Technical leadership in a mixed team includes making architecture teachable to collaborators who are not working in the same area every day.
- Google ADK and live audio pipelines require defensive state, session, and WebSocket handling when framework behavior is still changing.
- Judge-facing documentation should make the user problem, technical architecture, security posture, and evidence understandable without reading the entire repository.
Evidence available
- Public StoryForge repository and Cloud Run deployment record
- StoryForge progress log with 122 tests and end-to-end verification
- LinkedIn recommendation from the mentored student
- Public 8x Mobile starter repository and documentation
10 Crosswind Console Immersive AI research console coordinating travel, career, and trend agents across real-time APIs, RAG context, and persistent MCP connections.
Primary outcome
Reduced MCP tool-call latency from roughly 60 seconds to under 3 seconds while learning multi-agent orchestration, GCP administration, vertical data acquisition, and Three.js interface design.
120+ real-time tools and APIs Travel, hotel, weather, map, job, and trend data surfaced through MCP.
<3s documented tool latency Reduced from roughly 60 seconds after persistent HTTP pooling.
3 specialized agent lanes Travel, careers, and social trends.
What I built
- Three specialized agents for travel planning, career research, and social-trend analysis with a shared FastAPI and LangChain orchestration layer.
- A persistent HTTP MCP client and execution pool connecting more than 120 travel, flight, hotel, map, location, weather, jobs, and trend tools.
- A Svelte interface with a JavaScript and Three.js scene used as part of the visual control-console design.
- GCP virtual-machine experiments, service accounts, IAM, cloud APIs, Google OAuth, and Supabase pgvector retrieval.
What I learned
- Vertical agents need purpose-built access to domain APIs and data instead of generic web-search claims.
- Persistent connections and execution pooling can remove most of the latency caused by rebuilding tool sessions for every call.
- GCP service accounts, IAM, API enablement, OAuth, and VM lifecycle were easier to understand through one end-to-end product.
- Three.js can make an agent interface spatial and distinctive, but it should remain subordinate to the information workflow.
Evidence available
- Public source repository
- README architecture and documented sub-3-second tool latency
Evidence still needed
- Structured retrospective, API inventory snapshot, and representative interface captures
11 Tuur360 Estonia-wide 360-tour, drone-media, and Google Maps visibility service for hospitality, venues, and property businesses.
Primary outcome
Turned an existing Google Maps contribution practice into a measurable service offer with a public trust surface, delivery workflow, and pilot reporting plan.
What I built
- A production-ready Estonian Next.js site with structured data, sitemap, robots controls, Open Graph output, and Heroku deployment configuration.
- A capture-to-delivery workflow using Insta360, drone media, GoThru, Google Street View, client embeds, and channel-ready visual assets.
- A measured-pilot model that separates public media visibility from private Google Business Profile conversion evidence.
What I learned
- A strong view count can open a sales conversation, but it is not proof that a client received more bookings or visits.
- The useful case study starts with a before/after baseline and owner-shared profile actions, not generic industry statistics.
- A focused public site should support outreach and delivery instead of becoming a reason to delay direct prospect conversations.
Evidence available
- Live public website
- Private monorepo with current production source
- Google Maps contribution profile and published media
- Documented capture, publish, handoff, and pilot-measurement process
Evidence still needed
- First named client pilot with permission to publish results
- Before/after Google Business Profile actions and conversion evidence
- Client handoff artifacts and retrospective
12 PropertyReady Operating umbrella for property turnover, cleaning, helper labour, and professional visibility services built around one customer and evidence system.
Primary outcome
Designed one operating model that can move a property from post-renovation or tenant turnover to clean, documented, and listing-ready without creating disconnected service businesses.
What I built
- A versioned planning hub covering service scope, delivery, go-to-market, sales operations, contracts, technical hosting, and decision history.
- A private web monorepo that can add brand-specific applications only when each service line has operational proof.
- A local-first lead-system architecture with shared companies and contacts, separate business opportunities, explicit review, and a later on-premises API boundary.
What I learned
- One customer and handover journey can support multiple services, but each public brand should launch only after its delivery process is real.
- Technical polish is useful only when it improves outreach, delivery, measurement, or trust.
- A private lead system must keep prospect data, provider credentials, and outreach history outside the source repository.
Evidence available
- Internal service, operations, technical-delivery, and decisions documentation
- Private web monorepo containing the Tuur360 launch application
- Approved local-first lead-management architecture
- Contract and sales-material generation source
Evidence still needed
- Consolidated public project retrospective
- Revenue and delivery outcomes after the first operating pilots
- Implemented lead-extension MVP and on-premises service migration
13 PuhasValmis Planned property-preparation service for post-renovation cleaning, turnover work, handover readiness, and related B2B support.
Primary outcome
Converted a broad cleaning idea into a scoped, trigger-based B2B service with explicit exclusions, subcontractor controls, contract templates, and measurable launch gates.
What I built
- Defined service boundaries for post-renovation cleaning, landlord turnover, move-in or move-out work, helper labour, and handover-ready bundles.
- Created client and subcontractor contract templates, sales materials, delivery checklists, and a quote-from-photos operating concept.
- Designed a separate opportunity profile inside the PropertyReady lead architecture while sharing company and contact records with Tuur360.
What I learned
- Cleaning outreach should start with delivery capacity, scope, and partner relationships rather than waiting for another website.
- Trigger-based B2B targets such as renovation firms, property managers, and agents are more actionable than broad consumer marketing.
- Operational exclusions and replacement capacity are part of the product, especially when delivery is subcontracted.
Evidence available
- Internal service definitions and decisions log
- Generated client and subcontractor contract templates
- Sales collateral and operating checklists
- Profile support in the approved lead-system architecture
Evidence still needed
- Paid test job and delivery retrospective
- Verified subcontractor bench and replacement process
- Public site only after the offer and margins are proven
14 Kaelux.dev AI engineering business and public platform through which I delivered business automation, AI/ML integration, workflow engineering, and advisory work for multiple clients.
Primary outcome
Delivered client automation and AI/ML integration work, helped businesses introduce AI into existing workflows and projects, and created the operating and publishing surface used to present that work.
What I built
- Business automations delivered as a service for multiple clients, including workflow design, integration, implementation, and handoff.
- AI and machine-learning integrations for business workflows and product projects, combining consulting on where AI was useful with implementation inside the client environment.
- End-to-end OpenClaw setup and environment integration as a former service offering during its period of high client interest; this service is no longer offered.
- Offer-specific Instagram content using direct hooks and campaign strategies to attract attention to the OpenClaw setup service; the historical posts remain public, but campaign metrics are not published here.
- A production business site with technical positioning, service flows, project evidence, and diagnostic user experience.
- Deployment, observability, SEO, GEO, and documentation practices shared across public Kaelux projects.
What I learned
- Useful AI consulting starts with the business process, data, constraints, and expected outcome; adding AI to every workflow is neither necessary nor responsible.
- End-to-end deployment work includes environment discovery, credentials, networking, persistent data, observability, documentation, and client handoff rather than only installing software.
- Specific hooks and concrete offers created more attention than broad agency language, but public claims still need to remain scoped to evidence.
- Technical credibility depends on concrete evidence and clear scope more than broad service claims.
- Public documentation, search structure, and operational quality are part of the product surface.
Evidence available
- Live public platform
- Public website repository
- Deployment and content history
- Historical public OpenClaw campaign posts
Evidence still needed
- Template-backed case study
- Anonymized client delivery artifacts, outcomes, and testimonials suitable for public review
- OpenClaw campaign analytics export and canonical Instagram profile link
15 Examplayer Free exam-practice application that converts documents into structured questions or generates practice material with AI.
Primary outcome
Built a practical study interface around document processing, question structure, and repeatable exam practice.
What I built
- An exam-like practice experience for imported and AI-generated questions.
- Document-to-question conversion paths for turning existing learning material into reusable practice sets.
What I learned
- AI-generated learning content still needs deterministic structure and reviewable source material.
- Practice software is most useful when content ingestion and the testing interface remain separate concerns.
Evidence available
- Public source repository
Evidence still needed
- Learning outcomes, screenshots, and structured project retrospective
16 Kaelux Automate Custom n8n interface for generating and modifying workflow JSON with LLM assistance.
Primary outcome
Connected the Automation Atlas dataset work to an interactive workflow-generation product experiment.
What I built
- An n8n-oriented interface for prompt-driven workflow creation and modification.
- Dataset-backed experiments using structured workflow examples rather than isolated code snippets.
What I learned
- Workflow generation needs schema, node, and connection awareness in addition to natural-language intent.
- Retrieval data quality matters more than adding another correction loop without measured gains.
Evidence available
- Public source repository
- Related Automation Atlas dataset and case study
Evidence still needed
- Current product state, evaluation results, and screenshots