Kaloyan Ninov
Calgary, CanadaProjects, decisions,
and technical notes.
Complete progress log

Decisions, changes
& observations.

The full dated progress record, including technical work and personal reflections. Open an entry to read the full record.

Ed-Ready UI/UX Architecture

Advanced the Ed-Ready course-first experience

Expanded the platform’s course-first model with clearer private and public catalogs, adoption rules, permissions, and learner workflows.
  • Implemented the main catalog, course-building, publishing, and learner-facing interface flows.
  • Separated course ownership from adoption while keeping private content organization-scoped.
  • Updated the architecture direction and began local validation of the in-progress implementation.
Ed-ready Architecture + Authorization

Completed Ed-Ready PR 53 org-scoped lab ownership and Save Version foundation

Completed the major Ed-Ready PR 53 implementation and validation pass, expanding Save Version into a broader org-scoped authorization boundary across lab ownership, instruction management, deliverables, LTI launch, and immutable image-version registration.
  • Turned the original Save Version ownership foundation into a wider organization-scoped platform boundary covering org-owned lab definitions, org lab installation, creator/admin/owner authoring roles, public-lab adoption compatibility, and legacy lab backfill safety.
  • Added creator/admin/owner-gated Save Version registration through POST /api/labs/version, resolving authorization from lab_definition.ownerOrgId rather than trusting caller-supplied organization IDs.
  • Validated managed ECR image references for immutable lab environment versions, including allowed tag and sha256 digest references, duplicate-version conflict handling, and fail-closed behavior when server image-repository configuration is missing.
  • Moved lab definitions, instructions, deliverables, and questions onto org-scoped routes while retiring legacy global mutation paths with 410 responses and preventing adopting orgs from editing upstream canonical lab content.
  • Hardened launch and LTI boundaries by requiring org slug, labId, and instructionId, binding LTI course/context data to an EdReady organization, and only auto-adopting active public labs and instructions through the current compatibility path.
  • Finished frontend integration for org-scoped create/edit/list flows, active/inactive management states, learner-safe content reads, deliverable controls, visibility publishing, and removal of sensitive form-state logging.
  • Completed automated validation across lab image/versioning, org-scoped lab definitions, instructions, deliverables, LTI deep-link and launch behavior, createsession, legacy backfill, production build, database generation, TypeScript compile, Pulumi preview, and manual smoke-test coverage.
Client Delivery

Delivered Embrace Pediatrics client website

Delivered the final clinic website iteration, brought the production domain online, and set up the client's Google Maps business profile.
  • Merged the final website iteration into production.
  • Connected the custom domain and verified HTTPS.
  • Set up the Google Maps business profile for the clinic.
Ed-ready Documentation

Completed Ed-Ready documentation cleanup and audit

Finalized the Ed-Ready documentation cleanup by refreshing project-level docs, app-specific docs, and the dated documentation inventory before merging the cleanup PR.
  • Refreshed the top-level docs and app-specific docs under lab_platform/docs.
  • Removed temporary cleanup/audit files after the pass was complete.
  • Squash-merged the documentation cleanup PR into main.
AEGIS RAG Security Lab

Completed Phase 02 threat-model roadmap for AEGIS RAG

Finished the Phase 02 documentation polish for AEGIS RAG by turning the threat model into a builder-facing roadmap that maps retrieval risks, trust boundaries, attacker behavior, abuse cases, and future control placement across keyword, semantic, and GraphRAG retrieval.
  • Reviewed the current RAG architecture across keyword retrieval, semantic retrieval, and local GraphRAG to keep the threat model grounded in actual implemented system behavior rather than theoretical AI security coverage.
  • Expanded the Phase 02 threat-model overview with a documentation map, asset references, trust-boundary references, attack-path references, risk-register references, and control-backlog references so the artifacts link together cleanly.
  • Added a threat-to-boundary mapping that connects attack paths, trust boundaries, risk IDs, and future controls, making it easier for another builder to see where each defensive control should sit in the pipeline.
  • Documented attacker personas and abuse cases for direct keyword probing, semantic paraphrase leakage, poisoned source material, indirect prompt injection, graph traversal exposure, and missing auditability.
  • Added a control placement diagram showing where future checks belong before retrieval, during semantic filtering, before graph traversal, at context admission, during prompt construction, before output, and around telemetry.
  • Reframed the Phase 02 completion criteria as a threat-modeling roadmap for people implementing the system, then updated the README with Step 1 completed and Step 2/Step 3 plans for the prompt-injection lab and initial RAG security controls.
Client Website Consulting + Web Development

Advanced pediatric clinic website from rough direction to client-ready MVP

Continued a client website build for a pediatric clinic by turning loose design feedback into concrete UI, content, image, mobile, patient-form, and deployment-preview improvements suitable for a small healthcare business site.
  • Refined the pediatric clinic website after client feedback that the earlier layout felt too newspaper-like, shifting the design toward a warmer, photo-led pediatric clinic experience.
  • Reworked patient-facing copy across the site so forms, booking, contact, and service guidance read clearly for parents without exposing internal build language or unfinished implementation terms.
  • Replaced unstable placeholder imagery with approved local assets and mapped unique top, square, small-square, and footer images across Home, About, Services, and Patients pages.
  • Iterated on image treatments for the patient page, including custom triangular dimming that keeps the mother and child visible while softening the doctor side of the photo.
  • Tightened the mobile homepage card layout by reducing card width, padding, icon sizing, type scale, and spacing so the cards stay inside the frame and reveal more of the child-focused hero image.
  • Reviewed Netlify deploy-preview behavior and identified the branch-deploy setting needed for pull requests into v3 to receive preview comments while production remains on main.
AEGIS RAG + Tooling Diagnostics

Completed RAG threat modeling and documented ChatGPT connector failure modes

Closed the AEGIS RAG Phase 02 threat-modeling pass while also troubleshooting a ChatGPT/GitHub connector truncation issue and validating a practical desktop-app workaround.
  • Finished the Phase 02 threat-modeling work for AEGIS RAG by defining the initial AI security model around assets, actors, trust boundaries, retrieval-specific attack surfaces, attack paths, and control gaps.
  • Tested the GitHub connector truncation behavior with harmless repeated-text repro files and confirmed that long create_file/update_file arguments could be truncated before reaching GitHub while still reporting a successful commit.
  • Found that the ChatGPT Windows desktop app avoided the truncation behavior seen in the web flow, making it the practical workaround for longer repo-writing sessions.
  • Attempted to file the official ChatGPT bug report and found a second tooling defect: the report flow requested a HAR capture but did not accept HAR uploads.
  • Renamed the HAR capture with a .jpg extension so the uploader accepted it, then observed that the workaround broke the reporting AI tooling's file-type logic instead of producing a clean report path.
Portfolio UX + AEGIS RAG

Polished site responsiveness and started RAG threat modeling

Made a small but useful site polish pass while starting the threat-modeling documentation path for the AEGIS RAG Security Lab.
  • Tightened the project archive modal so mobile evidence links and lower detail sections stay contained instead of overflowing.
  • Cleaned up a desktop navigation hover rendering artifact that appeared against the terminal-style hero card.
  • Started threat-modeling documentation for AEGIS RAG, focusing on trust boundaries, retrieval-layer risks, and controls that need to be reasoned about before implementation is overstated.
Ed-ready Architecture

Started container-backed Save Version foundation

Implemented the first backend foundation for container-backed lab versioning by separating lab ownership, organization adoption, immutable image registration, and role-scoped access into clearer platform boundaries.
  • Added infrastructure support for a managed lab-image registry with immutable image references and safer deployment defaults.
  • Introduced data-model support for canonical lab definitions, organization lab installation, and container-backed lab environment versions.
  • Moved lab creation and read paths toward organization-scoped routes so private labs are not exposed through global endpoints.
  • Added creator-oriented authorization rules for lab creation, lab detail access, and version registration while keeping broader launch/update authorization as follow-up work.
  • Captured open product-model questions around public labs, organization adoption, creator roles, private org labs, and how version selection should work.
Ed-ready Cloud Smoke Testing

Closed the final cloud lifecycle validation loop

Completed the final Ed-ready cloud lifecycle smoke-test pass by validating the browser-driven lab launch path, confirming managed instance tagging and scheduled cleanup behavior, then documenting the remaining local-dev gaps as follow-up work rather than blockers.
  • Re-ran the isolated cloud stack after clearing test-environment cleanup friction from a prior destroy/recreate cycle.
  • Validated that the lifecycle API still rejects unauthenticated requests and fails closed when a request uses an unapproved lab image.
  • Wired the local lab application to the protected lifecycle API, created minimal local smoke-test data, and launched a lab through the actual Start Lab user flow.
  • Confirmed the launched lab instance carried the expected managed ownership, session, lab, and expiry metadata needed for lifecycle cleanup.
  • Manually expired the managed test instance, invoked the cleanup automation, confirmed termination, destroyed the cloud stack, and opened follow-up issues for local signup, seed-data, and desktop-connection developer-experience gaps.
Ed-ready Cloud Smoke Testing

Completed live AWS smoke testing for cloud lifecycle hardening

Completed an end-to-end cloud smoke test for Ed-ready lifecycle hardening, validating that the infrastructure can deploy, reject unauthorized access, create an authorized lab instance, verify lifecycle tags, terminate cleanly, and destroy cloud resources afterward.
  • Worked through several real deployment blockers that only appeared during live infrastructure validation, including packaging, container image, database configuration, and duplicate network-rule issues.
  • Kept the fixes scoped to deployment correctness and cloud portability rather than weakening the security intent of the pull request.
  • Ran local build, type-checking, Python syntax, Lambda artifact, handler-alignment, and sensitive-string review checks before deploying to AWS.
  • Validated the protected API path by confirming unauthenticated requests are rejected and authenticated lifecycle requests can create and delete a test lab instance successfully.
  • Confirmed expected instance ownership and cleanup tags, then destroyed the deployed cloud stack and verified the test infrastructure was removed.
Ed-ready Cloud Smoke Testing

Advanced AWS/Pulumi deployment validation

Set up an isolated AWS and Pulumi Cloud test path for Ed-ready lifecycle hardening, then validated the infrastructure preview before live deployment while keeping budget, cleanup, and deployment-scope controls explicit.
  • Configured AWS CLI, Pulumi CLI, Pulumi Cloud authentication, and a dedicated development stack to test outside the managed project account.
  • Set stack-level AWS region, admin network range, platform network range, and secret image allowlist configuration required by the hardened lifecycle deployment.
  • Rebuilt deployment archives and ran infrastructure preview against the cloud plan.
  • Identified and fixed a TypeScript module-resolution issue in the infrastructure entrypoint, then re-ran preview successfully with the expected deployment plan.
  • Paused before live deployment to review AWS budget guardrails, cost drivers, and manual cleanup paths for network, database, container, registry, API, and serverless resources.
Ed-ready Smoke Testing

Validated local smoke-test readiness for cloud lifecycle hardening

Completed the local, non-cloud validation path for Ed-ready lifecycle hardening, confirming the session lifecycle tests, production build, infrastructure TypeScript compile, and deployment artifacts before live AWS testing.
  • Ran the route tests for the lifecycle paths touched by the security hardening work and confirmed the expected passing test set.
  • Verified the application production build completes successfully and the infrastructure TypeScript project compiles without errors.
  • Built the deployment archives and confirmed the expected artifact paths are produced for the cloud deployment step.
  • Identified that remaining live cloud validation requires the managed AWS environment, CLI authentication, and appropriate read/deploy permissions before preview or deployment can be tested safely.
Ed-ready Architecture

Mapped a lab versioning workflow across virtual-machine and container paths

Reviewed a creator-facing lab versioning workflow against AWS container and virtual-machine patterns, then refined the abstraction into a clearer Save Version model without exposing private implementation details.
  • Clarified that the public product model should stay close to the creator workflow: open an editable lab environment, make changes, save a draft version, test it, and publish only after validation.
  • Separated the user-facing action from the backend artifact strategy so the same workflow can support different lab types without exposing infrastructure-specific language to creators.
  • Mapped the virtual-machine-backed path as a managed creator environment that can be saved into a new machine-image artifact, registered as a draft lab version, tested, and later published.
  • Mapped the container-backed path as a source or workspace change that builds a new immutable container image, pushes it to a registry with a versioned identifier, registers a new runtime definition, and records that as a draft lab version.
  • Validated that capturing a live running container is not the clean source-of-truth model for container lab versioning. The safer pattern is to treat container images as reproducible build artifacts.
  • Identified a practical early implementation path: pull an existing container image, edit and build locally or in a controlled workspace, push a new versioned image, and update the runtime definition for testing.
  • Kept the conclusion bounded: the abstraction appears sound, but the exact creator workflow for container-backed labs still needs implementation design, cost review, and live cloud validation.
  • Connected the design back to the current security review work: the active pull request hardens the lab lifecycle boundary, while full lab-version saving remains follow-up architecture work rather than completed behavior.
Ed-ready Security Review

Completed cloud lab lifecycle security hardening review and cleanup

Reviewed and cleaned up Ed-ready cloud lab lifecycle hardening from a security and deployment-readiness perspective, focusing on the cloud lab lifecycle boundary without exposing sensitive implementation details in public notes.
  • Reviewed the trust boundary between the web application, protected cloud endpoints, lifecycle automation, access roles, secrets handling, session cleanup, and deployment documentation.
  • Addressed a token-validation concern so authorization decisions are tied to the configured secret source rather than relying on stale process state.
  • Moved the session authentication guard earlier in the request flow so unauthenticated requests cannot progress into lookup, token generation, or infrastructure side effects.
  • Reduced access-role blast radius by separating authorization logic from broader lifecycle automation permissions.
  • Stopped exposing an incomplete machine-image capture path through the public lifecycle API and tracked the proper design as follow-up work instead of expanding the review scope.
  • Changed the lab launch path to fail closed when the approved image configuration is missing, preventing permissive behavior caused by deployment misconfiguration.
  • Adjusted short authorization caching so valid decisions work across the intended protected lifecycle routes without creating a long-lived stale-cache risk.
  • Removed raw request logging from lifecycle functions to avoid writing sensitive request material into operational logs.
  • Documented a one-time deployment caveat for older unmanaged lab instances so the new cleanup controls can be introduced safely.
  • Opened follow-up issues for larger architecture work: stronger role isolation, proper machine-image capture workflow design, final authorization cache strategy, and local developer-experience cleanup.
  • Triggered a final automated review pass after cleanup; the review returned with no major issues. Remaining validation depended on live cloud deployment testing.
Ed-ready Architecture

Advanced documentation audit and lab session flow mapping

Continued the Ed-ready documentation cleanup by turning rough architecture notes into clearer, reviewable documentation while keeping private implementation details out of public-facing project notes.
  • Reviewed top-level documentation status and separated documents that can be updated now from documents that should wait for maintainer approval.
  • Updated a frontend dependency hygiene note into repo-specific contributor guidance aligned with the current application package baseline.
  • Added a current lab session flow diagram to reduce reliance on an older visual sketch while keeping the original diagram file intact.
  • Marked the cloud quick start rewrite as approval-gated because it should reflect the accepted deployment path, not stale setup assumptions.
AEGIS RAG Security Lab

Implemented local GraphRAG retrieval for AEGIS RAG

Implemented Phase 01.75 by adding a local, deterministic GraphRAG retrieval layer beside the existing keyword and semantic retrieval modes, then merged it into main after reviewing the architecture and behavior.
  • Added graph nodes, graph edges, concept aliases, deterministic graph construction, traversal-based retrieval, a GraphRAG pipeline, CLI runners, tests, and phase documentation.
  • Validated the branch-per-phase workflow by preserving the GraphRAG phase branch as an architectural checkpoint while integrating the completed work into main.
  • Documented that retrieval quality depends heavily on the quality of the predefined concept map, aliases, relationship labels, traversal depth, and scoring rules.
  • Identified the next phase as retrieval-layer architecture review across keyword retrieval, semantic retrieval, and GraphRAG retrieval.
AEGIS RAG Security Lab

Kept Phase 1.75 moving during a low-output day

Logged a controlled recovery day: light RAG progress, small house-move progress, and personal maintenance without turning a low-energy day into a full stall.
  • Touched the RAG work enough to keep the project thread active.
  • Moved the house progression forward in a small but real way.
  • Chose recovery over forced late-night deep work so the next RAG session can start cleaner.
AEGIS RAG Security Lab

Added AI risk framework mapping to the RAG roadmap

Added a framework-mapping document to the AEGIS RAG Security Lab so the project can track AI system risks, planned controls, and implementation status against a recognized structure.
  • Created docs/owasp-llm-top-10-mapping.md in the AEGIS repository.
  • Mapped major AI application risk areas to project phases.
  • Kept the mapping conservative by separating implemented capability from planned controls instead of overstating coverage.
Portfolio Architecture

Implemented GitHub-backed project content architecture

Separated project content from the static site by creating a dedicated data repository and wiring the Projects page to render project cards and modal case files from external JSON.
  • Created structured project index and per-project JSON files in Personal_site_data.
  • Added dynamic project rendering to the frontend through projects.js.
  • Built styled project modals with status badges, stack tags, architecture areas, dated logs, evidence links, and next steps.
Portfolio UX

Refined project modal behavior and audience-facing copy

Adjusted the Projects page so project details read like professional case files for recruiters, interviewers, collaborators, and clients rather than internal build notes.
  • Removed visitor-facing implementation details about the data flow.
  • Changed the modal scroll model so the full project case file scrolls as one page.
  • Kept active and archived project states visible through status badges.
Personal Site

Converted the personal site from placeholder to multipage portfolio

Replaced the under-construction page with a designed portfolio structure focused on archived competence, technical projects, progress logs, operating principles, and contact flow.
  • Built separate pages for Home, Projects, Progress Log, Operating System, and Contact.
  • Kept main protected while working on the portfolio-archive-v1 branch.
  • Established the site as a professional footprint rather than a student-style assignment archive.
Personal Site

Updated branding, logo, and contact routing

Added the business logo, wired the professional email address, corrected inconsistent contact copy, and removed clickable behavior from the logo/name brand area.
  • Added Business Logo.png to the site branch and styled it into the navigation brand area.
  • Updated contact routing to use kal@ninov.dev across homepage and contact page.
  • Made the logo/name static across the site to avoid unwanted navigation behavior.
AEGIS RAG Security Lab

Reviewed retrieval architecture from a risk perspective

Analyzed how keyword retrieval, semantic retrieval, and GraphRAG change the risk profile of a RAG system and what coverage remains incomplete.
  • Compared retrieval layers by their different exposure to noisy inputs, trust boundary confusion, and context manipulation.
  • Identified that multiple retrieval methods improve coverage but do not automatically solve authorization, provenance, evaluation, or output-control risks.
  • Prepared the next phase around retrieval-layer control design.
AEGIS RAG Security Lab

Prepared next implementation phase for RAG architecture work

Reviewed the current state of the RAG lab and prepared the direction for the next phase of implementation, study, and documentation.
  • Kept the branch-per-phase workflow intact.
  • Prioritized baseline implementation clarity before adding advanced controls.
  • Focused the next phase on architectural reasoning, not just code generation.
Professional Positioning

Turned LinkedIn and GitHub activity into archived competence strategy

Clarified the role of public technical work as a durable evidence trail for recruiters, mentors, and future technical interviews.
  • Framed public posts and repository work as long-term signal rather than short-term validation metrics.
  • Reviewed how GitHub commits, project docs, and LinkedIn updates compound into credibility over time.
  • Separated visible progress from vanity engagement metrics.
Ed-ready Architecture

Started deeper technical orientation around Ed-ready architecture

Reviewed the technical stack and began organizing the system into learnable architecture domains for onboarding and future documentation work.
  • Identified the frontend application, cloud services, access controls, containerization, remote lab delivery, realtime communication, and user flow as key areas to understand.
  • Positioned the work as architecture comprehension and documentation alignment rather than surface-level repo cleanup.
  • Prepared the path for a structured documentation audit.
Ed-ready Architecture

Created direction for a 10-day technical onboarding architecture

Structured a learning path for understanding the Ed-ready codebase and technical stack in a way that supports useful contribution and architecture discussion.
  • Mapped the stack into domains: frontend, cloud services, storage, identity, lab delivery, and system communication.
  • Focused the onboarding plan on producing practical understanding instead of passive reading.
  • Aligned the work with technical clarity, initiative, and documentation standards.
Career Architecture

Aligned project work with mid-tier cybersecurity positioning

Connected active project work to the goal of presenting as a technical professional who can explain architecture, risk, and system behavior clearly.
  • Focused on communication, architectural explanation, and evidence-backed project work as interview leverage.
  • Positioned AI systems, application architecture, cloud architecture, and project documentation as connected signals.
  • Reinforced the strategy of building proof rather than relying on credentials alone.
Professional Communication

Tightened public technical writing standards

Reviewed the tone and formatting of public technical posts so the writing sounds authored, concise, and professionally credible.
  • Removed formatting patterns that can make posts feel generated or over-polished.
  • Focused on concise architecture-oriented updates rather than generic AI enthusiasm.
  • Kept the writing grounded in what was built, reviewed, or learned.
AEGIS RAG Security Lab

Established AEGIS RAG as a portfolio-grade AI systems lab

Set the direction for AEGIS RAG Security Lab as a structured AI architecture project for interviews and professional review.
  • Defined the lab around RAG systems, governance, monitoring, and adversarial testing concepts.
  • Used a branch-per-phase workflow to preserve learning and implementation history.
  • Positioned the project as an architecture reasoning artifact, not just a code repo.
Portfolio System

Defined the personal site as an archive of competence

Clarified that the site should function as a personal blog and professional footprint that stores proof of work over time.
  • Set the direction for a deliberate portfolio instead of a generic resume site.
  • Focused the architecture around projects, logs, technical decisions, and documented progression.
  • Prepared the site to become a long-term professional evidence layer.