Explore the portfolio

WorkExperienceSkillsAboutContactDiscover everything

Open to AI/ML and software engineering internships.

Gaurav Kumar Nayak / Portfolio 2026

GauravKumar Nayak.

Software engineering.
Applied AI. Real evidence.

CS student building reliable backends and useful AI tools. I care about what happens after the happy path.

Open to AI & software engineering internships

View my work Resume

B.Tech · C.V. Raman Global University · Expected 2028

Scroll through the full portrait story

Curiosity

I turn
magic into
logic.

AI starts with a possibility. Engineering makes its behavior inspectable, testable, and useful.

Approach

Build it.
Break it.
Understand it.

Durable requests, explicit approvals, useful interfaces, and honest evaluation. The details are the work.

Selected work

The work.
And the evidence.

Explore the implementation, tradeoffs, measured behavior, and limits behind each project.

Explore projects

Selected work

The work behind the words.

A closer look at the systems I am building: what they do, how they work, and where they still need work.

Recorded Kairos overview with a development investigation, observed result, and source patch
Recorded overview of a development investigation. The full investigation is linked in the case study; fresh validation is a separate result.
Engineering prototype

Kairos

Inspectable AI code-repair investigations

A code-repair workbench that keeps original source, proposed patches, independent checks, and observed outcomes inspectable together.

My workBuilt durable, inspectable repair workflows with fenced workers and independent verification. Local release acceptance passed 428 backend checks; model repair quality is evaluated separately.

Backend checks passed
428
14 October 2026 local release acceptance: 6 explicit opt-in skips, zero failures or errors. Software validation is separate from repair quality. Validation notes
Browser journeys passed
24
Eight evidence-viewer, eleven fault-fixture, four real-OIDC and one separate real-model development journey. These are different test scopes, not 24 repair successes. Validation notes
  • Next.js
  • FastAPI
  • PostgreSQL
  • Python
Case study

Why I built it

A plausible generated patch needs an inspectable source context, execution history, and independent checks before a reviewer can assess it.

What it does

  • Inspect original source and proposed patches
  • Review independent checks and saved evidence
  • Resume durable authenticated investigations

How it works

  • Next.js evidence viewer and authenticated workbench.
  • FastAPI with PostgreSQL request receipts, ordered steps, tenant roles, and worker leases.
  • Local inference, disposable Docker checks, and digest-addressed artifacts.
Design decisions
  • Commit accepted requests before acknowledging them.
  • Keep interrupted inference explicitly unknown instead of silently repeating it.
  • Use independent checks to determine patch outcomes.
Validation & limitations

What was checked

  • 14 October 2026 local acceptance collected 434 backend tests: 428 passed, 6 explicit opt-in skips, zero failures or errors. Saved receipts: evidence/docs008/checks/backend-summary.json and fullstack-acceptance.json.
  • Twenty-four browser journeys passed across separate scopes: 8 evidence-viewer, 11 fault-fixture, 4 real-OIDC, and 1 exposed development-case model journey. This is software workflow coverage, not a repair-success count.
  • A saved Django development repair was reproduced against its registered checks. Fresh repair validation verified 0/10 attempts across five qualified cases; the development success is separate.
  • The completed 12 October 2026 local control-plane repeat processed 435,270 requests over approximately 42 minutes with zero unexpected errors. Its ten-client, 30-minute soak recorded acknowledgement p95 275.19 ms and read p95 16.79 ms. It used real HTTP/PostgreSQL and fixture identity/tasks, without inference or OIDC throughput. Saved receipt: evidence/build004/capacity-summary-final.json; earlier failures remain preserved.
  • The source repository is private. These notes summarize locally inspected receipts; source files and downloadable receipts have not been published here.

Current limits

  • None of the ten fresh repair attempts across five qualified cases passed the registered verification checks. This measures model repair quality, not backend reliability. The single reproduced development repair was a separate, already-exposed case; broader repair usefulness remains unproven.
  • Recorded inspection does not run a new investigation or change a visitor's repository.
  • Local control-plane capacity does not establish production scale or inference throughput.
AgentSentry workspace with an approved action, execution state, and audit events
Actual governed-action workspace with synthetic orders and a simulated recipient service.
Measured development system

AgentSentry v2

Governed action execution

An approval-gated support-action system with durable execution, explicit authority, recipient receipts, and recovery after worker failure.

My workCompleted 128 synthetic actions with 128 recipient receipts in a bounded hosted run by combining approval-bound actions, fenced workers, and receipt reconciliation.

Completed synthetic actions
128 / 128
13 October 2026 hosted bounded workload, with 128 recipient effect receipts. Four callers, two workers; not saturation or a production SLA. Validation notes
  • Go
  • PostgreSQL
  • Python
  • JavaScript
Case study

Why I built it

An action can outlive an HTTP response or a worker. Retrying without recipient evidence can repeat the external effect.

What it does

  • Propose and approve exact action hashes
  • Inspect execution state and audit events
  • Reconcile recipient receipts after failure

How it works

  • Go API, PostgreSQL approval/action storage, and a separate Go worker.
  • Browser workspace for proposals, approval, saved state, and audit events.
  • Authenticated simulated order API with SQLite receipts and an experimental typed model-draft path.
Design decisions
  • Bind approval to the exact action hash; strict mode requires a different authorized approving actor.
  • Check recipient receipts before retrying an uncertain action.
  • Separate model draft quality from execution correctness.
Validation & limitations

What was checked

  • 13 October 2026 hosted CI verified a dated engineering baseline, including recovery, race checks, browser workflows, and restore drills.
  • A bounded synthetic hosted workload completed 128 actions with 128 effect receipts; it is not a production SLA or saturation result.
  • The frozen model evaluation stopped at 62/80 cases and already failed its declared utility and safety gates.

Current limits

  • AI quality qualification remains open. Engineering checks do not qualify autonomous decisions.
  • The simulated recipient supplies explicit idempotency and receipt guarantees that arbitrary external APIs may lack.
  • No customer deployment or API cost saving is claimed.
Artha workbench with a selected replay and original saved scoring result
Actual synthetic replay with a saved result. This screen is not a live model-accuracy measurement.
Historical ML study + workbench

Artha

Temporal ML evaluation and durable replay

A transaction inspection workbench combining prior-only features, versioned model artifacts, tenant-scoped access, and exact saved-result retries.

My workShared prior-only feature construction between offline and serving paths, then added atomic SQLite replay and role-controlled inspection.

Shared scoring features
8
Four current-input and four prior-history features use the same offline and serving module. Implementation fact, not a quality score. Validation notes
Local scoring p95
16.77 ms
12 October 2026 client-inclusive measurement: 4,800 generated unlabeled scores over 120 seconds, four clients at 10 requests/s each, zero failures. Not saturation or production latency. Validation notes
  • FastAPI
  • SQLite
  • scikit-learn
  • Python
Case study

Why I built it

Evaluation and serving can disagree when features include future information or retries recalculate accepted transactions.

What it does

  • Inspect original saved scoring results
  • Retry accepted transactions without re-scoring
  • Use tenant-scoped reader, writer, and admin roles

How it works

  • One feature module for offline preparation and serving.
  • Versioned scikit-learn artifact, runtime manifests, and export/reload parity checks.
  • Tenant-scoped FastAPI, SQLite replay history, and browser workbench.
Design decisions
  • Exclude the current observation from its own historical counts and amount means.
  • Commit input, original features, response, revision, and audit together.
  • Return the original saved result on exact retries.
Validation & limitations

What was checked

  • The 10 October 2026 historical study used a chronological 100,000-row prefix with separate fit, calibration, selection, and historical final partitions.
  • Historical fixed-threshold precision was 9.23% and recall was 41.28%; most alerts were false and most fraud was missed.
  • The dated hosted engineering baseline at 676a4795ba04a7bb2acf2bf573826a6e9d77311a, run 38409317955, passed 404 Python tests with zero failures, errors or skips. CI uses synthetic model fixtures and separately exercises parity, roles, retries, browser behavior, restart recovery, and same-host restore.
  • A separate 12 October 2026 local workload completed 4,800 generated unlabeled scores over 120 seconds, with four clients paced at 10 requests/s each, zero failures and client-inclusive p95 16.77 ms. This is one selected-model development-host measurement, not fraud accuracy, saturation, a speedup, or a production SLA. Saved receipt: reports/operating-2026-10-12/selected-model-001/report.json; documented in docs/resume-contract.md.
  • The repository was not publicly accessible on 14 October 2026. These notes summarize locally inspected source and receipts; downloadable receipts are not attached.

Current limits

  • Historical full-source exposure cannot be ruled out. The old final partition is development-only for future work.
  • No independently unseen production fraud-prevention result is claimed.
  • Raw transactions and model weights remain unpublished; redistribution permission is unreviewed.
Recorded CineNexus browsing interface with movie hero, navigation and profile entry points
Recorded movie discovery screen with the catalogue hero, navigation, and profile entry points.
Full-stack application

CineNexus

Movie discovery and shared viewing

A cinema-style discovery application connecting browsing, profiles, recommendation experiments, and shared-viewing workflows.

My workBuilt the discovery interface and connected profile, recommendation, playback-progress, and watch-party workflows across the frontend and API.

Product workflows
4 connected areas
Discovery, profiles, recommendations, and shared viewing are represented in source. Implementation scope; no user-adoption count. Validation notes
  • React
  • FastAPI
  • MongoDB
  • Redis
Case study

Why I built it

Movie discovery, personal profiles, and shared viewing need to feel like one coherent product.

What it does

  • Browse films by genre and language
  • Keep profile-specific lists and viewing history
  • Explore shared-viewing and recommendation workflows

How it works

  • React application with profile context and routed discovery screens.
  • FastAPI services with MongoDB persistence, Redis/Celery work paths, and recommendation modules.
  • Separate streaming, catalogue, and watch-party integrations.
Design decisions
  • Keep profile state distinct from account identity.
  • Separate browsing and recommendation concerns from playback and payment actions.
Validation & limitations

What was checked

  • Current source contains the routed discovery, profile, recommendation, and shared-viewing interfaces.
  • The recorded interface capture is preserved whole. Current local catalogue loading did not complete during review; no live playback, payment, or recommendation-quality check was performed.
  • No user count, revenue result, streaming capacity, or recommender accuracy is inferred from the interface.

Current limits

  • Backend/provider availability determines catalogue, recommendation, and playback behavior.
  • A watch-party interface is not a measured concurrency result.
  • Source was not anonymously accessible under the former portfolio URL on 14 October 2026.
TritonForge workbench showing RMSNorm source and an estimated A100 roofline plot
Current interactive kernel workbench. Analysis and illustrative IR are labelled as estimates, without GPU execution.
Kernel engineering workbench

TritonForge

A workbench for understanding GPU kernels

Explore kernel source, hardware constraints, illustrative compiler passes, and roofline estimates alongside separate Triton kernel experiments.

My workBuilt an interactive source-and-inspector workbench with kernel presets, hardware choices, parameter controls, and explicit separation between static estimates and measured GPU behavior.

Kernel presets
4
Four authored frontend source presets for inspection. This is workbench scope, not a GPU benchmark. Validation notes
Hardware profiles
4
Static hardware specifications in the analyzer. Selecting a device does not run code on that device. Validation notes
  • Python
  • PyTorch
  • Triton
  • TypeScript
Case study

Why I built it

Kernel code and hardware constraints are difficult to reason about when memory movement, tiling, and generated representations remain disconnected.

What it does

  • Inspect and edit kernel presets
  • Explore hardware and tile parameter choices
  • Compare illustrative IR and roofline estimates

How it works

  • Next.js and React workbench with an editable source pane.
  • TypeScript static analyzer derives illustrative compiler representations and hardware estimates.
  • Separate Python/Triton kernel implementations and hardware-specific correctness/benchmark paths.
Design decisions
  • Expose hardware assumptions beside the estimates.
  • Keep frontend analysis distinct from actual Triton compilation and GPU execution.
Validation & limitations

What was checked

  • The current frontend source has four kernel presets and four hardware specification profiles. These are implementation counts, not measured hardware runs.
  • The local browser workbench renders source, parameter controls, and analysis output. No GPU benchmark was executed for the portfolio.
  • Historical T4 speedup tables require independently inspectable hardware receipts; those values are not used as portfolio performance claims.

Current limits

  • The browser analyzer does not invoke a real Triton GPU compiler.
  • Illustrative IR, occupancy, and roofline output do not prove device execution or speedup.
  • Kernel correctness and performance depend on hardware, shapes, layouts, and numerical tolerances.

AI-assisted development. Current solo work and earlier team projects are labelled individually. Case studies distinguish implemented behavior, measured results, and limitations.

Discover all projects & repositories

A closer look / Kairos

Good systems make uncertainty visible.

Follow a request from acceptance to inspectable evidence.

Interactive architecture

From request to evidence.

An illustrated view of Kairos. Select a stage to inspect its responsibility.

Request

A registered investigation starts with a bounded request and a stable identity.

Architecture illustration. Measured results and model limits live in the case study.

Read the case study

More to explore

Different problems. Same curiosity.

Applied AI, optimization, collaboration, and developer tools. Each project opens into its own technical story.

ForgeGuard Contain workspace showing supplier-notice exposure and review state
Current containment workspace using synthetic records. The authored example path is labelled no model run.
Locally verified prototype

ForgeGuard Contain

Supplier-quality containment workflow

Turns a supplier notice into record-backed exposure, a revision-bound human decision, and durable inventory or task actions in a sandbox.

My workConnected lot tracing, revision-bound approval, durable sandbox receipts, and explicit pending inference states.

Authored fault scenarios
40 / 40
Stored local synthetic-fixture checks: stale approval, duplicate intent, fencing, lost acknowledgement, and recovery. Live model qualification remains open. Validation notes
  • React
  • FastAPI
  • PostgreSQL
  • Python
Case study

Why I built it

Supplier notices need traceable affected lots and approvals that remain valid only for the reviewed record revision.

What it does

  • Trace notices to affected demonstration lots
  • Approve the exact reviewed revision
  • Recover sandbox actions through durable receipts

How it works

  • React case register and review interface.
  • FastAPI with SQLite development storage and a PostgreSQL deployment adapter.
  • Bounded inference worker and sandbox inventory/task actions.
Design decisions
  • Invalidate stale approvals when the reviewed record changes.
  • Keep authored examples visibly separate from live model requests.
  • Show unavailable inference as pending instead of manufacturing a result.
Validation & limitations

What was checked

  • Stored local evidence records 40/40 authored fault scenarios covering stale approval, duplicate intent, fencing, lost acknowledgement, and recovery.
  • Real HTTP and PostgreSQL adapter checks exercise authority, revision, persistence, and receipts.

Current limits

  • Demonstration notices, records, and policies are authored synthetic fixtures.
  • Live model quality, AMD workload, and public deployment are not qualified.
  • A sandbox hold is a software state change. No factory savings or physical containment result is claimed.
HyperFlow BasketOps interface with workspace and reviewer connection controls
Current BasketOps interface in disconnected mode. No live purchase or backend result is shown.
Local engineering prototype

HyperFlow

Reviewable commerce workflows

A commerce prototype connecting basket optimization, approval boundaries, reconciliation, durable jobs, and experimental demand modeling.

My workImplemented solver-backed baskets and reconciliation, then strengthened action approval, workflow state, and experiment provenance.

Basket optimization
MILP
A solver-backed implementation with stock constraints and re-solving. This describes the algorithm, not measured sales impact. Validation notes
  • FastAPI
  • React
  • Python
  • MILP
Case study

Why I built it

An optimized basket still needs stock reconciliation, approval, and recoverable provider actions before it becomes an executed order.

What it does

  • Optimize baskets with stock constraints
  • Re-solve after cart reconciliation
  • Review approval state before provider actions

How it works

  • React workbench and FastAPI services.
  • MILP solver with stock constraints and reconciliation-driven re-solving.
  • Provider adapters, durable job paths, replay scenarios, and separate model fit/evaluation artifacts.
Design decisions
  • Keep a proposed basket distinct from an authorized provider action.
  • Re-solve after stock or cart constraints change.
  • Separate synthetic demand experiments from operational commerce metrics.
Validation & limitations

What was checked

  • Basket optimization uses an actual MILP solver; reconciliation adjusts constraints and re-solves.
  • Demand studies measure relative WMAPE improvement on synthetic censored rows, not recovered real sales.
  • These notes describe the current local workflow. No operational commerce benchmark or public receipt download is attached.

Current limits

  • No recovered revenue, live operational accuracy, or deployment-wide provider execution is claimed.
  • Older repository material can contain superseded claims. This case study describes the narrower current scope.
  • Authenticated provider execution depends on actual credentials and availability.
NexGrid Studio editor displaying labelled sample code and execution controls
Current local editor with labelled sample code. No active collaborative session or executed result is shown.
Collaboration prototype

NexGrid

Collaborative code editor

A shared coding workspace exploring CRDT synchronization, WebSocket collaboration, and code execution workflows.

My workBuilt a shared editing interface around CRDT synchronization, WebSocket events, and execution feedback.

Document synchronization
CRDT
Implemented collaborative document model. This preview has no active multi-user session; no concurrency scale is claimed. Validation notes
  • React
  • JavaScript
  • WebSockets
  • CRDT
Case study

Why I built it

Concurrent edits must converge while document state and execution feedback remain understandable.

What it does

  • Edit a shared CRDT document
  • Synchronize changes over WebSockets
  • Inspect execution feedback

How it works

  • Browser editor and workspace.
  • CRDT shared document with WebSocket synchronization.
  • Separate execution and result-presentation workflow.
Design decisions
  • Use a shared document model for concurrent changes.
  • Present execution feedback separately from document synchronization.
Validation & limitations

What was checked

  • Source and local interface demonstrate collaborative editing and execution workflows.
  • No published large-scale concurrency or latency benchmark is attached.

Current limits

  • Prototype status does not imply a hardened public code-execution service.
  • Inference-gateway throughput and accelerator results do not apply to this project.
CodeSage source explorer with sample files, definitions, and parsed call relationships
Current source explorer with a bundled local sample. Symbols and call edges are parsed from the displayed source; no model answer is shown.
Developer tooling prototype

CodeSage

Repository intelligence and graph inspection

Explores code through AST call graphs, dense and lexical retrieval, and an interface for inspecting repository relationships.

My workConnected AST-derived relationships to dense/lexical search and inspectable repository context.

Retrieval paths
Dense + lexical
Implemented code-context retrieval paths. This preview shows a labelled local sample, not a retrieval-quality benchmark. Validation notes
  • Python
  • FastAPI
  • React
  • AST
Case study

Why I built it

Understanding a repository requires definitions, calls, and relationships as well as matching text.

What it does

  • Inspect AST call relationships
  • Search code with dense and lexical retrieval
  • Explore indexed repository context

How it works

  • Python source parsing and graph construction.
  • Dense and lexical retrieval over indexed code.
  • React graph interface and experimental training tools.
Design decisions
  • Keep structural relationships alongside retrieved text.
  • Expose selected context for inspection.
Validation & limitations

What was checked

  • Current source contains parsing, retrieval, graph inspection, and experimental training paths.
  • No qualified H100 training, universal context-size, or model-accuracy result is claimed.

Current limits

  • Graph completeness depends on parser coverage and dynamic code behavior.
  • Experimental training tooling does not establish trained model quality.
QualEdge model and OOD controls with pending pipeline stages
Current model and OOD controls with pipeline stages pending. No NPU measurements or completed run are shown.
Optimization workbench

QualEdge

ONNX optimization workbench

Compares quantization and execution-provider options while retaining accuracy gates, benchmark context, and fallback behavior.

My workBuilt ONNX candidate comparisons with accuracy gates and explicit provider fallback.

Optimization acceptance
Accuracy gated
Candidates are checked against accuracy constraints. No device-specific speedup or NPU run is established by the preview. Validation notes
  • Python
  • ONNX Runtime
  • React
  • Quantization
Case study

Why I built it

A faster model is not useful when accuracy regresses or the preferred execution provider is unavailable.

What it does

  • Compare ONNX optimization candidates
  • Reject accuracy regressions
  • Inspect execution-provider fallback

How it works

  • ONNX optimization and quantization pipeline.
  • Provider benchmarking and accuracy comparisons.
  • Browser workbench for results, rejected candidates, and fallback state.
Design decisions
  • Check accuracy before accepting an optimization.
  • Preserve the measured runtime and device context.
Validation & limitations

What was checked

  • Local workbench supports benchmark comparisons and accuracy-regression rejection.
  • Hardware-specific results require actual device receipts; no blanket NPU speedup is claimed.

Current limits

  • Results are specific to model, data, provider, and device.
  • Provider availability does not prove accelerator execution on an unmeasured device.
Browse the project archive

In the repository

Small steps, committed.

203 contributions in GitHub’s published calendar.

GitHub profile

Saved GitHub snapshot · 14 Oct 2026

The calendar reflects activity visible on the public profile. Explore the code and project notes for the engineering itself.

Experience

Practice beyond personal projects.

FlyRank

Machine Learning Engineering Intern program

Completed internship program

FlyRank

July 1 – August 12, 2026

Completed the six-week program during the stated dates. The original acceptance letter, approved June 27, 2026, records the role and July 1–August 12 schedule. It is not a completion certificate or evidence of client impact.

  • Developed applied machine-learning and software engineering skills during the program.
  • Personal portfolio projects are documented separately from the program. No client revenue, production deployment, or employer-owned project result is attributed here.
View program document

Skills & evidence

Tools mean more
when you can show the work.

Capabilities demonstrated in the projects above. Open the evidence to see the implementation, tradeoffs, and limits.

Applied AI & evaluation

Connect model workflows to inspectable context and evaluate them with visible limitations.

  • scikit-learn
  • Retrieval
  • AST
  • Model evaluation
  • ONNX

See the work

Temporal MLRepository retrieval

Frontend & interaction

Make saved state, review decisions, and failure states understandable in a browser.

  • React
  • Next.js
  • TypeScript
  • JavaScript
  • CSS
  • WebSockets

See the work

Evidence inspectorCollaborative editor

Data & delivery

Preserve exact results, compare model candidates, and exercise software through behavioral checks.

  • SQLite
  • PostgreSQL
  • Docker
  • Git
  • CI
  • Behavioral testing

See the work

Saved-result replayAccuracy gates

Always learning. I use documentation and AI tools during development; the linked case studies show what I have built and validated.

About

Learning by building.
Growing by testing.

I am a computer science undergraduate building AI and software systems, from inspectable code repair to durable action execution and transaction replay. I care about understandable interfaces, recoverable workflows, and evidence that shows both what works and what still needs work.

GitHub LinkedIn

Education

B.Tech in Computer Science and Engineering, C. V. Raman Global University · Expected 2028

How I work

AI-assisted development. Current solo work and earlier team projects are labelled individually. I document validation and limitations alongside the features.

What is next

Open to AI/ML and software engineering internships.

Developer growth arc

What changed as I kept building.

A few real chapters, with the work and records behind them.

  1. 2025

    Getting the foundations right

    SQL coursework and early application projects gave me a practical way to learn how software and data fit together.

    Udemy
    Learning records
  2. 2026

    Learning through the work

    Machine learning and full-stack coursework, followed by projects in retrieval, recommendations, and collaborative interfaces.

    MetaIBMStanford OnlineDeepLearning.AI
    Projects and repositories
  3. July – August 2026

    A structured program

    Completed the FlyRank Machine Learning Engineering Intern program, July 1–August 12. Personal projects remain documented separately.

    FlyRank
    Program experience
  4. October 2026

    Asking harder questions

    Added durable requests, recovery checks, reproducible evaluation, and clearer evidence. Failed model checks now stay beside the software results.

    Engineering evidence

Recognition & learning

Milestones, with context.

Selections, participation, and completed learning are described separately, with the available source attached.

MetaHugging FaceScaler

Finalist selection

2026

OpenEnv AI Hackathon

Meta · OpenEnv · Hugging Face · Scaler

My team was selected among 800 finalists from 31,000+ registered teams. The saved selection notice names Gaurav Kumar and the Bangalore finale on April 25–26. This is finalist selection, not an overall win or a global rank.

Original document
IISc BangaloreArtPark

Participant

2026

ArtPark CodeForge Hackathon

ArtPark · IISc Bangalore

Participated in the build-and-submit prototype development round with SkillBridge, a learning-path prototype.

Original document

Continued learning

Learning & community

Courses, workshops, and events.

Each mark connects to a named record in the library.

IIT BombayIIT BombayIIT RoorkeeIIT RoorkeeIIT GuwahatiIIT GuwahatiIIT DelhiIIT DelhiNIT RaipurNIT RaipurNIT DurgapurNIT DurgapurIISc BangaloreIISc BangaloreMetaMetaHugging FaceHugging FaceIBMIBMStanford OnlineStanford Online
Discover all eventsDiscover all certificates

Writing

Thinking, written down.

Articles and technical case studies, labelled for what you will find when you open them.

The full collection

There is more to explore.

All project stories, public repositories, learning records, and event documents have a home.

34 stories · 35 public repos

Projects & repositories

The full build log. Systems, experiments, and the source behind them.

Discover all
17 learning records

Certificates & learning

What I studied, who taught it, and the records to check.

Discover all
38 event entries

Events & community

Hackathons, workshops, and participation — each with its own context.

Discover all
15 original files

Original documents

Look through the original certificates and program files.

Discover all
Contact

Let’s build
something useful.

Open to AI/ML and software engineering internships. I would love to discuss the engineering behind these projects and what I could contribute to your team.

gauravnayak711@gmail.com

GitHubLinkedIn

This form sends your message through Formspree.

Find your way

12 results found.

Use Tab or arrow keys to explore. Enter opens a result. Escape closes search.

Portfolio assistant

Answers from published portfolio records.

A closer look

Find the work behind the skills.

Ask about engineering decisions, validation, experience, or project limitations. Each answer links back to its sources.

AI can make mistakes. Check the linked records. Your question is sent to Google Gemini.