Github Profile

I use the AgriDataValue Environmental Data for Powdery Mildew, Downy Mildew; DOI 10.5281/zenodo.14989522; 2025; CC BY 4.0 as the primary source for my vineyard environmental project.

My classroom vineyard dataset has 1,511 original records from 2020 through April 2024; synthetic/noised archive files excluded.

The vineyard data contains air temperature, air humidity, rainfall, and mildew labels; nutrient sensing is a proposed student extension, not existing data.

I use a chronological split, more demanding and more honest than randomly mixing nearby dates.

My PlantVillage references are the Kaggle PlantVillage mirror; PlantVillage-Dataset primary project reference; Mohanty, Hughes & Salathé 2016 validation reference.

My PlantVillage scope is potato early blight, potato late blight, and healthy potato images; smaller three-class task fits a free notebook and leaves room for two models.

PlantVillage has controlled backgrounds; validation score is not proof of field accuracy.

My grapevine spectra source is Zhang, Perrin, Vrabie, Goupil & Panon, Multi-annual spectral data of Chardonnay grapevine leaves, version 1.1, 2025, Etalab Open Licence 2.0; Scientific Data.

The official grapevine source contains 14,636 spectra from 350–2500 nm at 1 nm intervals, plus expert field labels and year/site metadata.

My grapevine classroom transformation uses real 400–1000 nm measurements averaged into 60 adjacent 10 nm bands; no synthetic values added.

The source workbook about 420 MB; transformed compressed CSV roughly 3 MB, practical on a free Kaggle CPU.

My data/README.md contains column definitions, transformation details, licensing, and regeneration instructions.

No honest project can promise 100% model accuracy or 100% field success; disease labels contain uncertainty, weather and varieties change, and controlled images differ from farms.

I check row counts, class counts, years, wavelength bands, and required columns.

All notebook JSON and Python cells pass structural/syntax validation.

The tabular tasks can fit their proposed model families within ordinary CPU resources.

The PlantVillage folder layout and potato class names were checked against the Kaggle listing and primary dataset references.

The verification described does not guarantee perfect accuracy or field success.

My notebooks intentionally do not contain final fitted models, answer metrics, or a copy-paste training solution.

I propose six sessions for the teaching schedule.

Session one is Question and provenance: read the source and write what the target does and does not mean.

Session two is Data audit: run checks, inspect imbalance, and make one original plot.

Session three is Baseline and split: explain why the chosen split is fair and calculate the simplest baseline.

Sessions four and five ask students to implement assigned model and record first validation result; change one setting, compare errors, and freeze model.

Session six is Final test and presentation: open held-out test once where supplied, compare both students, show mistakes, and state limitations.

Each team submits a completed notebook, one-page results sheet, three-minute presentation, and short statement of who completed which work.

I regenerate materials with python tools\build_materials.py with --environment-source-dir and --spectral-xlsx arguments.

I chose the vineyard dataset because its official record supplies both environmental measurements and mildew labels across multiple years.

The two included classroom files were rebuilt from the named official sources.

I validate the materials locally with python tests\validate_materials.py.

My build script accepts nested environmental archive folders, excludes synthetic files by name, checks the official spectral headers, and refuses unexpected row counts.

I maintain Global Commodity Trade Analytics, a Python-backed coursework project for COMP482, KU-DOCSE(IV/I), on my GitHub. It is an interactive dashboard for exploring international commodity trade data from 1988 to 2016, with a deployed site and a local development workflow.

My Global Commodity Trade Analytics project started 2026-06, last updated 2026-09, and uses Python.

The dashboard supports trade summaries and trends; country and regional comparisons; trade balances and map-based exploration; country growth profiles; product diversification and change drivers; product-level breakdowns, category trends, and commodity search; representative data preview and CSV export; advanced analysis.

Advanced analysis includes forecasting, anomalies, clustering, correlation, and concentration measures.

My deployed dashboard is available at global-commodity-dashboard.vercel.app.

The project has a React frontend and a Python FastAPI backend.

React handles the interface, charts, filters, and navigation; Python handles data loading, validation, aggregation, analytics, and API responses.

Production data is kept as versioned Parquet artifacts stored outside the repository.

For ordinary dashboard requests, DATA_BASE_URL retrieves compact analytical cubes; detailed data is read lazily for previews and product-level analysis.

The original CSV is intentionally excluded from Git because it is large; its local path is CSV Dataset/commodity_trade_statistics_data.csv, where the backend can build and use cached artifacts in outputs/.

I deploy the application as two Vercel projects: global-commodity-api for the FastAPI backend and global-commodity-dashboard for the Vite/React frontend.

The stated local prerequisites are Python 3.12 or later and Node.js 20 or later, plus npm.

I keep the large source CSV and generated or sensitive deployment material out of version control: the repository .gitignore excludes the original CSV, generated Parquet files, local environment files, build output, and object-storage credentials.

python -m pip install -r requirements.txt
cd frontend
npm install
cd ..

$env:DATA_BASE_URL = "https://bhvquuvpxslxofra.public.blob.vercel-storage.com/global-commodity/v2"
$env:CORS_ORIGINS = "http://localhost:5173"

python -m uvicorn app:app --reload --port 8000

# In a second terminal:
cd frontend
npm run dev

The local API runs at http://localhost:8000 and the frontend at http://localhost:5173. I can verify the backend with the test suite and build the frontend for production.

python -m unittest discover -s tests -v
cd frontend
npm run build

I completed Global Commodity Trade Analytics as coursework for COMP482, KU-DOCSE(IV/I).

I document a quick-start path for laya nepali: install the package in an editable virtual environment, run the verification checks, start the clothing-domain inference server, and try either the conversational endpoint or the Jev-compatible endpoint.

git clone https://github.com/DontHash/laya-nepali.git
cd laya-nepali
python -m venv .venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate
pip install -e ".[dev,serve]"

The verification guide reports 185 tests in the pytest suite.

python -m pytest -q
python -m layanep.eval --check
ruff check src/ tests/ --line-length=120

# CPU
python -m layanep.serve --model-path data/checkpoints/clothing_v1 --domain clothing --device cpu --port 8000
# CUDA
python -m layanep.serve --model-path data/checkpoints/clothing_v1 --domain clothing --device cuda --port 8000

The guide shows POST /v1/message for conversational inference, with text, domain, business_name, and business_state in the JSON request. Its clothing example asks about cash on delivery outside Kathmandu and uses a business state with COD enabled and delivery areas in Kathmandu, Pokhara, and Butwal.

The sample /v1/message response reports label: "cod", tier: 0, auto_served: true, confidence: 0.9412, latency_ms: 28.4.

In the sample /v1/message response, I show the reply: "Hamro Fashion मा क्यास अन डेलिभरी उपलब्ध छ।"

The sample business state reports cod_available: true; delivery areas: काठमाडौं, पोखरा, बुटवल; fee: 150.

The guide also documents POST /v1/systemone as a Jev-Wire-compatible endpoint. Its example request supplies state.customer_message, business_name, and domain; the guide does not give a full API specification.

I describe the training and evaluation data as custom accumulated and curated conversational datasets collected for Nepali commerce environments. The provenance notes describe PII scrubbing, multilingual composition, and intent-family partitioning.

The dataset is described as Zero PII; scrubbed phone numbers matching \b9\d{9}\b, personal names, locations, email addresses, and URLs.

The multilingual dataset split is 34% Romanized Nepali (NepGlish), 33% Devanagari, and 33% English.

Dataset partitioning is Partitioned strictly by intent families so benchmark test instances never appear in the training split.

The project licenses are Code: Apache License 2.0; Data & Benchmarks: CC BY 4.0.

Nandha Kishor M designed and open-sourced the foundational Laya System 1 decision architecture.

TypeSafe AI pioneered the non-autoregressive System 1 decision model philosophy behind Jev.

The project is Developed by DontHash; tailored for the Nepali Digital Economy.

I describe laya-nepali as my Python repository on GitHub: an open-source Jev alternative for Nepali conversational commerce. It adapts the System 1 decision-model idea to Devanagari, Romanized Nepali (NepGlish), and local commerce needs.

My laya-nepali repository is Python and was last updated 2026-10.

The project exposes the Jev-compatible drop-in endpoint POST /v1/systemone.

The model evaluates intent in one forward pass instead of generating token streams sequentially.

The serving layer supports both clothing (retail/fashion) and restaurant (food ordering) domains.

The response engine combines classified intent with live business state, including catalog, inventory, pricing, and delivery tiers, to fill Nepali responses using templates.

The project's README reports restaurant v16 latency of 28 ms p50 on 2×T4 and clothing latency of 64 ms p50 on an RTX 2050; it also reports CPU latency of 8.0 s p50.

The comparison table reports restaurant latency of 28.1 ms on 2×T4 and clothing latency of 63.9 ms on an RTX 2050, while listing generative LLM latency as 1,500 – 3,500 ms.

The comparison table lists cost per 1,000 decisions as < $0.001 for Laya and $5.00 – $15.00+ for generative LLMs.

The comparison table lists Laya's model size as 643 MB and generative LLM model size as 14 GB – 70 GB+.

Tier 0 auto-serves routine informational queries only when calibrated confidence is ≥ τ and p_none is below its threshold; Tiers 1–3 escalate mutations, complaints, and ambiguous fragments to a human operator queue.

• Routine query labels include catalog, price, size, color, material, stock, delivery, cod, and hours; checkout and exchange mutations, and skin sensitivity, counterfeit, and damage complaints, are escalated.

The measured operating points are dated 2026-10-09 and come from a tier-policy simulation on the frozen cl-bench-v1 held-out test split of 805 steps.

At τ 0.9 / p_none < 0.02, clothing v1 recorded 574/805 (71.3%), abstain 259/264, 5 unsafe auto-serves of 208 served, ECE 0.0551, and p50 94.5 ms.

At τ 0.4, clothing v1 recorded 766/805 (95.2%), 7 raw false commands, 16 unsafe auto-serves of 365 served, ECE 0.0742, and p50 78.5 ms.

The restaurant v16 checkpoint recorded 93.0% accuracy (253/272) at τ 0.4, 0 unsafe auto-serves on held-out data, abstain recall 92/92, and ECE 0.0699; its weights are not in the repository.

The project says order_status and cart are always-escalate labels and never auto-serve; cod asserts availability only when the caller stated cod_available: true.

The benchmark table reports generative LLM accuracy of ~62.3%, abstain recall of ~68.4%, ECE > 0.2200, and frequent hallucinations; its listed latency is ~1,850 ms and CPU latency ~8,400 ms.

The project reports 185 unit and integration tests in its pytest suite.

I keep measured results distinct from the README's broader positioning claims: the frozen-benchmark reports are the source of truth, while example confidence scores are illustrative from an early serving run. Clothing latency varies by measurement context, laptop runs are noisy, and a production T4 measurement is pending. The clothing simulation's unsafe auto-serves and raw false commands should not be conflated with the comparison table's broader “0 false commands” claim. The full clothing reports are reports/cl-bench-v1-laya-tau09.md and reports/cl-bench-v1-laya-tau04.md.

The project says Jev does not understand or support Nepali, Romanized NepGlish, or local commerce logistics, including COD policies, valley versus out-of-valley delivery, local sizing, and payment conventions.

The project says its models are fine-tuned on custom accumulated and curated conversational datasets spanning pure Devanagari, Romanized Nepali (NepGlish), and English.

The comparison table describes Laya's NepGlish / Romanized fluency as native and generative LLM fluency as poor or unstable.

My NepTrans v4 adapts OpenAI Whisper large-v3 using LoRA for Nepali transcription and Nepali–English code-switching.

I trained NepTrans v4 on 21,470 clips / 49.094 hours of conversational and read speech.

I recommend the complete CTranslate2 model for local transcription and self-hosted applications; its weights are approximately 1.55 GB.

I provide the original LoRA adapter for Transformers/PEFT experiments and further adaptation; it requires the original base checkpoint.

Both NepTrans model repositories provide a pinned v4.0.0 release, model cards, license notices, evaluation summaries, and checksums.

I document Python 3.10 or newer as the requirement for using the repository.

The first run downloads the complete model from Hugging Face; subsequent runs use the local cache.

The public NepTrans weights require no Hugging Face account or paid endpoint; users supply their own compute.

My default inference configuration is CPU with int8 compute; the NVIDIA GPU path requires CUDA 12 and cuDNN 9 libraries.

The helper prints text by default, while --output writes UTF-8 text and --json-output writes segment timestamps and detected-language metadata.

Standard faster-whisper language detection uses the first 30 seconds and does not identify language switches word by word.

For Nepali-led recordings I suggest trying --language ne, and for English recordings --language en; I recommend checking results on the recordings.

After the model is downloaded, inference can run offline; audio stays in the runtime the user controls, and the helper does not send it to a NepTrans service.

The helper provides segment timestamps but does not perform speaker diarization or produce verified transcripts.

I intend NepTrans for draft transcripts, interview notes, subtitles, and applications where a person reviews the output.

Names, numbers, English technical words, punctuation, script choice, and noisy or overlapping speech can be wrong; Whisper-family models can repeat or hallucinate text over silence or unclear audio.

A self-hosted NepTrans API must provide its own authentication, storage policy, and concurrency controls.

My saved internal development evaluation for selected checkpoint 4,026 measured 28.17% WER and 11.16% CER across 652 clips.

My saved internal formal-test evaluation measured 36.47% WER and 19.24% CER across 625 clips.

These evaluation results are saved Transformers/PEFT training-run results on internal splits, not FLEURS or Common Voice benchmarks; I did not rerun the full evaluation on the quantized CTranslate2 model and claim no leaderboard ranking.

My inference helper and documentation use the MIT license.

My released model artifacts use Apache-2.0, with upstream notices retained in the model repositories.

My training included a curated OpenSLR-54 subset; its CC BY-SA 4.0 dataset license and Google attribution are documented in NOTICE, and the training data is not included.

git clone https://github.com/DontHash/neptrans-asr.git
cd neptrans-asr
python -m venv .venv
python -m pip install -r requirements.txt
python transcribe.py recording.wav --output transcript.txt --json-output segments.json

python transcribe.py recording.wav --device cuda --output transcript.txt

The repository includes the inference helper and user documentation, while the model weights are hosted on Hugging Face. For runtime setup and troubleshooting, I point users to docs/USAGE.md. I ask issue reporters to include the command, Python and package versions, device, model revision, and a sanitized error message; recordings should only be shared with permission, and credentials or private recordings should not be uploaded.

I started the neptrans-asr repository in 2026-10.

My neptrans-asr repository topics include automatic-speech-recognition, code-switching, ctranslate2, faster-whisper, huggingface, lora, nepali, nepali-asr, nepali-speech-recognition, neptrans, offline-transcription, self-hosted, speech-to-text, whisper, and whisper-large-v3.

My DontHash GitHub profile README presents my local-first Python work across ML pipelines, media automation, and experiments I use. Its featured project is ClipClipper, alongside several smaller or exploratory repositories.

My DontHash repository is my GitHub profile README, started 2026-07 and last updated 2026-07.

I build local-first Python tools — ML pipelines, media automation, and experiments I actually use.

I describe ClipClipper as a YouTube clip-finding engine and a viral moment finder for long-form YouTube.

ClipClipper downloads video with yt-dlp, transcribes with Whisper, and ranks moments with OpenAI/Gemini plus replay heatmaps, audio energy, and chapters.

ClipClipper writes its ranked output to clips.json; optional ffmpeg cuts retain the source aspect ratio.

pip install -r requirements.txt

python main.py "https://www.youtube.com/watch?v=VIDEO_ID" --num-clips 5

My example ClipClipper command requests 5 clips from a YouTube video.

I list crispy-pannacotta as a place for snippets, drafts, and references.

I list crispy-pannacotta at https://github.com/DontHash/crispy-pannacotta.

I list NepaliMusicRecommendation as music recommendation work.

I list NepaliMusicRecommendation at https://github.com/DontHash/NepaliMusicRecommendation.

I list RayMozic as a side project.

I list RayMozic at https://github.com/DontHash/RayMozic.

The stack I list for this profile is Python, ffmpeg, yt-dlp, faster-whisper, OpenAI / Gemini, and numpy.

I link the featured ClipClipper project to https://github.com/DontHash/Optimized-AI-ShortsGenerator.

I compare VeriScript with other OCR systems on a frozen, table-heavy Devanagari benchmark. The canonical write-up is docs/BENCHMARK.md; raw lab notes and reproduction commands are in evals/bakeoff_results.md.

On the frozen Devanagari hard-10 benchmark, Surya OCR 2 has mean CER 0.166 [0.100–0.258], median CER 0.107, bagCER 0.360, and speed 172.0 s/page; its result is GPU-class. Its benchmark result is mean CER 0.166 [0.100–0.258], median CER 0.107, bagCER 0.360, 172.0 s/page; GPU-class.

On the same benchmark, Qwen3-VL-8B NF4 has mean CER 0.176 [0.129–0.235], median CER 0.141, bagCER 0.369, and speed 152.7 s/page; its result is GPU-class. Its benchmark result is mean CER 0.176 [0.129–0.235], median CER 0.141, bagCER 0.369, 152.7 s/page; GPU-class.

My default VeriScript pipeline has mean CER 0.255 [0.202–0.329], median CER 0.227, bagCER 0.376, and speed 7.3 s/page; it is CPU-first. Its benchmark result is mean CER 0.255 [0.202–0.329], median CER 0.227, bagCER 0.376, 7.3 s/page; CPU-first.

The raw RapidOCR engine has mean CER 0.530 [0.463–0.585], median CER 0.543, bagCER 0.380, and speed 3.8 s/page; it is CPU-first. Its benchmark result is mean CER 0.530 [0.463–0.585], median CER 0.543, bagCER 0.380, 3.8 s/page; CPU-first.

PaddleOCR 3.x full pipeline has mean CER 0.662 [0.585–0.713], median CER 0.687, bagCER 0.400, and speed 21.8 s/page in this CPU measurement. Its benchmark result is mean CER 0.662 [0.585–0.713], median CER 0.687, bagCER 0.400, 21.8 s/page; CPU measurement.

Across all benchmark arms, bagCER ranges from 0.360–0.400, suggesting similar glyph recognition while page-level differences reflect reading order, table structure, and digit handling.

On the same frozen pages, VeriScript improves CER over raw RapidOCR from 0.530 → 0.255 while remaining CPU-first, offline, and Apache-2.0.

Surya 2 has the best median CER but takes ~23× VeriScript’s page time and uses OpenRAIL-M weights.

The GPU arms invent text absent from the source, producing 82–224 tokens over the 10 pages; the content says only this stack ships an alternative-reading digit review queue.

The test suite is described as approximately ≈336 collected tests, covering OCR, export, routing, CLI and web behavior, layout and orientation, language plumbing, evaluation gates, Devanagari line-reader and training workflows, lexicon tools, data builders, PDF text-layer extraction, logging, and Markdown export.

The repository layout separately describes the test suite as ~338 tests.

I keep the repository to code and evaluation evidence only: no training datasets, no model checkpoints and no redistributed third-party corpora.

Evaluation manifests record hashes and provenance, while data stays local: data/, weights/ and artifacts/ are git-ignored.

I build the optional Devanagari lexicon locally from Apache-2.0 and MIT sources using scripts/fetch_nepali_lexicon.py; it is built locally and is not redistributed.

My project and component licenses are: MIT project license; RapidOCR/PP-OCR Apache-2.0; reportlab/pypdfium2 permissive; PySide6 LGPL; UltraSharp CC-BY-NC-SA excluded from commercial builds.

My evaluation measurements come from hash-frozen sets with bootstrap 95% CIs; full tables, provenance and rebuild commands are in docs/EVALUATION.md.

My repository states: “No number in this repo is marketing.”

My orientation evaluation result is 16/16 synthetic; 0/30 false rotations on upright real scans; 90/90 rotated pages decided.

For modern government PDFs, my raw Devanagari engine result is CER 0.135 [0.097–0.186], exact-token recall 0.877 (n=41, Gemini-2.5-Pro anchor GT, engine-corroborated).

For letterpress books, my Devanagari result is CER 0.434 [0.387–0.481] raw; 0.373 under the default auto line reader (42/69 pages engaged, Appendix AE); exact-token recall 0.647 (n=69, human-corrected ALTO GT).

My rendered-fixture results are clean CER 0.030/0.028; degraded ne 0.094 (pass) / hi 0.170 (heavy fails).

For Devanagari, my digit-review setup is default ON: review-queue digit-content recall@10 0.85 government PDFs / 0.91 letterpress; 0.93 on the human-audited residual of the PDF set (owner-verified real errors); the digit-first queue doubles precision@10 (0.10 → 0.21 PDFs; 0.15 → 0.36 letterpress), ≈ +0.4 s/page.

My review flags and calibration are 'script_mismatch, invalid_sequence (impossible combining sequence), isotonic cal_conf; ECE 0.82 → 0.30 on scans; optional unknown_word lexicon flag (needs scripts/fetch_nepali_lexicon.py) lifts the frozen-PDF review queue R@10 0.148 → 0.175 with the digit queue unchanged'.

My optional Bodhan digit verifier --digit-verifier bodhan flags 0.71 recall / 0.81 precision; opt-in (cost gate failed: +8.3 s/page).

For multi-page PDFs, my behavior is --max-pages 0 → every page + <stem>_combined.pdf/.txt; GUI "All pages" checkbox.

My two-column reading-order result on the arXiv set is arXiv set WER 0.870 → 0.268 (−69%) on split pages; >2 columns unsupported.

My phone-photo proxy result—not real-photo evidence—is CER 0.370 medium / 0.757 heavy (clean 0.135) — recognition, not honesty, is what breaks.

My mixed-page router result and status are restored text + untouched logos/photos (non-text PSNR 60–67 dB vs 18–23 dB naive); 1 invented token on photo texture → not auto-enabled.

My real-page detection result is covers 97.5% of ALTO line boxes (area view) — recognition, not detection, is the bottleneck.

My image-path default is Since 2026-10-01 the image paths (CLI and web studio) default to the auto line-reader gate — running text + aged paper only; PDF inputs keep the engine reading.

I use VeriScript’s document pipeline through its CLI or web studio. Both produce searchable PDFs, overlays or restored images, transcripts, Markdown, and OCR JSON; photo upscaling remains a separate CLI mode.

# Photo/scan in: searchable PDF + overlay + transcript + Markdown + JSON out
python cli.py --mode document --input page.jpg --output out/run1

# PDF in: first page by default; --max-pages 3 = first three pages
python cli.py --mode document --input scan.pdf --output out/run1 --max-pages 3

# PDF → Markdown: per-page .md always; --max-pages 0 adds one combined .md
python cli.py --mode document --input report.pdf --output out/report --max-pages 0

# Same CLI as a module / installed console script:
python -m veriscript --mode document --input report.pdf --output out/report

# Photo upscaling (shares the same CLI/app)
python cli.py --mode photo --input photos/ --output out/upscaled --scale 4

The available CLI knobs “all default to the measured best configuration”: --ocr rapidocr|tesseract, --lang en|ne|hi, --deskew, --no-reading-order, --rotate auto|off, --repass-digits/--no-repass-digits, --digit-verifier off|bodhan, --no-pdf, --no-overlay, --no-txt, and --no-md.

My VeriScript CLI options include --ocr rapidocr|tesseract, --lang en|ne|hi, --deskew, --no-reading-order, --rotate auto|off, --repass-digits/--no-repass-digits, --digit-verifier off|bodhan (optional second-model digit check), and --no-pdf --no-overlay --no-txt --no-md.

My web studio is described as: “The single UI — FastAPI + SolidJS, running the same pipeline and outputs (searchable PDF, transcript, Markdown, OCR JSON) as the CLI.”

pip install -r webapp/requirements-web.txt    # backend, on top of requirements.txt
cd webapp/frontend && npm install && npm run build && cd ../..
python webapp/server.py                       # http://<redacted>:8000

pip install -r webapp/requirements-web.txt    # backend, on top of requirements.txt

cd webapp/frontend && npm install && npm run build && cd ../..

I can consult docs/DEPLOY.md for hosted deployment guidance covering Docker, basic auth, HF Spaces, Render, and Fly.

My VeriScript deployment guidance covers Docker, basic auth, HF Spaces, Render, and Fly.

The server’s privacy boundary is: “The server binds to localhost by default; the pipeline, models and any training artifacts stay server-side.”

The scope decision is: “The photo upscaler is CLI-only (its weights are non-commercial); the web studio is document-only”. I keep photo upscaling out of the web studio because its weights are non-commercial.

For JS/TS integrations I have a typed HTTP client in packages/veriscript-client. Its npm package status is “veriscript; not published yet”.

The web studio’s canonical artifact names are restored.png, searchable.pdf, transcript.txt, transcript.md, ocr.json, combined.md.

For multi-page PDFs, the per-page filenames include report_p000.pdf, report_p000.md.

Combined output is “all pages joined with --max-pages 0; the combined Markdown has one ## Page N section per page”.

Markdown is produced by default. I can skip the .md files with --no-md in the CLI or the Markdown toggle in the web studio. The studio’s scope is documented in docs/PLAN_WEB_FULL.md.

The web studio’s scope is documented in docs/PLAN_WEB_FULL.md.

I built VeriScript as an offline, local-first document-restoration project. It is intended to process photos, scans, and PDFs on my machine, with a focus on Nepali and Hindi Devanagari documents and support for English.

My VeriScript project is described as: Offline document restoration: photo/scan in, searchable PDF + honest review flags out.

My VeriScript language focus is: Devanagari (Nepali/Hindi) first. English is also supported by the same pipeline.

My VeriScript project dates are: Started 2026-08, last updated 2026-10.

My VeriScript privacy model is: Everything runs on your machine. No cloud calls, no telemetry, no account. The pipeline runs with networking disabled.

My document pipeline is: photo/scan/PDF ──▶ orientation ──▶ layout ──▶ OCR ──▶ risk flags ──▶ searchable PDF.

The pipeline produces a cleaned page and review-oriented outputs, including an overlay, text transcripts, Markdown, and OCR JSON. The review approach is intended to surface uncertainty rather than silently resolve it.

In VeriScript, digits are the highest-risk tokens: they are re-read, risk-ranked and put in a review queue instead of being silently guessed.

VeriScript’s review queue is measured, not asserted; the README points to docs/EVALUATION.md.

My project describes Devanagari as a first-class citizen, not a language pack. Frozen evaluation sets with published numbers and confidence intervals cover letterpress books, modern government PDFs, and phone photos.

VeriScript’s before-and-after colors are: Green = accepted, amber = uncertain, red = digit conflict with the alternative reading kept.

The letterpress page used in the VeriScript demo is from heiDATA (doi:10.11588/data/EGOKEI, CC BY 4.0).

The photo row in the VeriScript demo is this repository's own synthetic fixture under a simulated phone shadow.

pip install veriscript
python -m veriscript --mode document --input page.jpg --output out/run1

• My VeriScript installation options are: pip install veriscript installs the document pipeline and CLI without torch; pip install "veriscript[photo]" adds photo upscaling with torch; pip install "veriscript[verifier]" adds the optional bodhan digit verifier.
• From a source checkout, requirements.txt installs the full runtime including torch; requirements-dev.txt adds optional development and evaluation tooling.

Optional Tesseract 5 can be a second OCR backend for clean-scan fallback and the OSD rotation fallback.

I can regenerate the VeriScript before-and-after demo image with python scripts/make_demo_image.py.

The VeriScript hosted demo was retired on 2026-10-10 and the cloud deployment was removed; the re-deploy guide remains in deploy/gcp-cloudrun.md.

The captured README says evaluation uses frozen sets and published numbers and confidence intervals, but it does not include the actual metrics or confidence-interval values. I still need to consult the evaluation documentation for those figures, as well as the exact review-flag thresholds, verifier and fallback limitations, and redeployment steps.

My GitHub profile is @DontHash. It shows my software and applied-AI work, including Nepali language technology, document restoration, conversational commerce, coursework, and exploratory projects. My NepTrans work is also described on linkedin profile.

I have been on GitHub since 2024.

My GitHub profile has 10 followers.

My profile lists 18 repositories.

Across the repositories, the listed language counts are Python (12), C++ (3), Jupyter Notebook (1).

My profile lists one merged pull request to another project.

My neptrans-asr repository describes Nepali speech-to-text and Nepali-English code-switching ASR.

The method described for neptrans-asr is: Run the NepTrans v4 Whisper large-v3 fine-tune locally with faster-whisper on CPU or NVIDIA GPU.

The neptrans-asr repository details are Python, 1 star; last updated 2026-10.

The neptrans-asr weights are on Hugging Face.

My VeriScript repository describes its method as: Offline document restoration: photo/scan in, searchable PDF + honest review flags out.

The language focus for VeriScript is Devanagari (Nepali/Hindi) first.

VeriScript is described as Local, no cloud calls.

The VeriScript repository details are Python; last updated 2026-10.

My VeriScript repository is hosted on my GitHub account, @DontHash.

My VeriScript repository topics are: devanagari, document-ocr, document-restore, nepali, ocr, offline, pdf-to-markdown, python, searchable-pdf.

My laya-nepali repository describes itself as: Jev for Nepal: High-Speed System 1 Decision Model for Nepali Conversational Commerce (<30ms, Devanagari & NepGlish).

The laya-nepali repository details are Python; last updated 2026-10.

I describe crispy-pannacotta as A mixed bag of code snippets, references, drafts, or anything else worthwhile to store and revisit; perfection or structure is not the goal.

The crispy-pannacotta repository details are Python, 1 star; last updated 2026-08.

The NepaliMusicRecommendation repository details are Python; last updated 2026-10.

The GlobalCommodity repository details are Python; last updated 2026-09.

My nba-2026-27-merch-market-study repository is an NBA 2026-27 t-shirt market study for Philadelphia, Miami, and Meta ads targeting; last updated 2026-08.

My plant-disease-detection-guided-projects repository contains Beginner-friendly guided notebooks for environmental, RGB image, and visible/NIR plant disease detection projects; Python; last updated 2026-08.

My plant-disease-detection-guided-projects repository provides Beginner-friendly guided notebooks for environmental, RGB image, and visible/NIR plant disease detection projects.

My repository metadata says: Started 2026-08, last updated 2026-08.

The repository contains three intentionally incomplete Jupyter notebooks for three teams of two high-school students.

Each notebook supplies the real dataset, loading code, integrity checks, experiment rules, evaluation helpers, and scientific limitations.

Students still have to design and train the models, justify choices, compare results, and explain errors.

For paired comparisons, the two students in a team use the same data split and evaluation contract.

Project 1 is environmental mildew risk using Temperature, humidity, rain; Student A uses Logistic regression, Student B uses Random forest, and CPU is sufficient.

Project 2 uses Ordinary colour images; Student A builds a Small CNN and Student B uses MobileNetV2 transfer learning, with GPU recommended.

The RGB image project's three-class subset is also small enough for a slower CPU experiment.

Student B needs ImageNet MobileNetV2 weights.

The transfer-learning warning is explicit: Do not use weights=None and call it transfer learning.

Project 3 uses 400–1000 nm reflectance; Student A uses Linear SVM, Student B uses Random forest, and CPU is sufficient.

The notebooks provide structured starting points rather than finished model results: students are expected to train and compare models and explain their errors. No experimental scores or conclusions are included in this material.

The two supplied files together are about 3.2 MB.

The first and third notebook paths are notebooks/01_environmental_mildew_risk_guided.ipynb and notebooks/03_visible_nir_spectra_guided.ipynb; for both projects, create a small private Kaggle Dataset containing the repository's data folder, upload the chosen notebook, attach the private dataset with Add Input, and run from the top.

For Projects 1 and 3, a CPU session is sufficient, and internet access is not required after the data is attached.

For Project 2, upload 02_rgb_leaf_image_guided.ipynb and attach the mohitsingh1804/plantvillage Kaggle dataset: https://www.kaggle.com/datasets/mohitsingh1804/plantvillage.

For Project 2, select a free GPU accelerator if one is available; its three-class subset can also be run as a slower CPU experiment.

To obtain Student B's ImageNet MobileNetV2 weights, enable Internet for the first download or attach those weights as another Kaggle input.

For robust Kaggle input handling, the notebook searches the usual /kaggle/input/ paths and prints a clear message when an input is missing.

I host the plant-disease-detection-guided-projects repository on @DontHash’s GitHub.

I designed the shared data split and evaluation contract to make the students’ model comparison meaningful instead of turning the work into two unrelated projects.

My notebooks account for occasional Kaggle interface changes.

The DontHash repository is my GitHub profile README; last updated 2026-07.

I describe Edu-slab as the current version of an older EduAssess-style repository: a full-stack, AI-assisted learning platform for assessments, progress tracking, peer matching, and personalized study support.

My Edu-slab repository is on @DontHash’s GitHub, uses Python, and was started 2026-07 and last updated 2026-07.

• I describe Edu-slab’s learning features as: adaptive assessments for Math, Science, and English; AI-assisted answer evaluation and feedback; chapter-level performance tracking and weakness detection; peer-to-peer matching based on strengths, gaps, and location preferences; and personalized learning roadmaps and resource recommendations.

I organized Edu-slab as separate backend and frontend applications for API and UI concerns.

• My Edu-slab backend stack is FastAPI, SQLAlchemy, SQLite, Pydantic, JWT auth, FAISS, and Mistral/Ollama integrations; its frontend stack is React, Vite, TanStack Query, Zustand, React Router, Tailwind CSS, and Recharts.
• I use backend/ for the FastAPI application, services, migrations, and data loaders; frontend/ for the React/Vite user interface; python_RAG/ for RAG preparation and content-processing scripts; and scripts/ for utility scripts for validation and generation.

cd backend
python -m venv venv
venv\Scripts\activate
pip install -r requirements.txt
python main.py

cd frontend
npm install
npm run dev

My Edu-slab .gitignore is configured for Python, Node, IDE, and generated AI/cache artifacts.

Some legacy files and datasets remain from Edu-slab’s older repository structure; I have left open whether to keep or trim them as cleanup continues.

My contribution guidance for Edu-slab is to create a branch, make focused changes, and open a pull request with a clear summary of the behavior changed.

The Edu-slab repository details are Python; last updated 2026-07.

The RayMozic repository details are Python; last updated 2026-07.

My Compiler_lab repository is Made for COMP 409; Python; last updated 2026-06.

My CompGraphicsLab repository contains Computer Graphics lab reports and assignments; Python; last updated 2026-01.

My TalentScout repository is A simple chatbot attempt using LLAMA and OPENAI API, with Streamlit and NGROK; Python; last updated 2025-08.

My Malariaaaa repository is a Malaria detection AI model taking cell images as input; Jupyter Notebook; last updated 2024-10.

My CE_Lab_4_Sort repository implements insertionSort() and QuickSort() and analyzes them based on input size (n); C++; last updated 2024-06.

The CE2022_Lab3_-11-_-12- repository details are C++; last updated 2024-06.

My TestOne repository is a GitHub repository for lab session; C++; last updated 2024-05.

My merged pull request is recorded as 1 merged pull request to Pratik-Pokhrel/Google-TMT-Hackathon, titled “Safe Batching and Lossless Translation ”.