Skip to content

DraftLint Upstream

Status: Active upstream source Owner: Sreekar Reddy, Sajjala Last verified: 2026-07-16

Source And Runtime Identity

  • Variant ID: draftlint-upstream
  • Canonical local repository: /Users/adeelyj/code/local ai server setup/DraftLint
  • Additional local checkout: /Users/adeelyj/code/sreekar-draftlink-BOM-frontend/draftlint-source
  • Remote repository: sreekarrs/DraftLint
  • Active/default branch: main
  • Verified commit: aaa9947a3e3aad81e24e50e826716cd7ad564470
  • Runtime: local Python/Docker application; no Adeel-hosted production deployment is recorded for this exact branch
  • Successor for Adeel's deployment needs: DraftLint Railway Validator
  • Not to be confused with: the IONOS detector gateway or the RapidDraft product UI

Responsibility

DraftLint Upstream is the friend-owned source from which the Railway adapter was forked. Its stated purpose is full ISO/ASME technical-drawing validation using document processing, layout analysis, OCR, YOLO symbol detection, optional LLM assistance, rule validation, and report generation.

The upstream repository should remain clean of Adeel-specific Railway, IONOS, and local-AI connection changes. Those changes belong in the fork so upstream improvements can be reviewed and integrated deliberately.

Upstream Workflow

Step What happens Main code Execution boundary
1 Load PDF/image, rasterize, resize, preprocess src/processors/document_processor.py Local
2 Run five groups of drawing-region/symbol models src/processors/inference_runner.py Local YOLO runtime when weights are available
3 Parse FCF compartments and GD&T symbols src/processors/fcf_parser.py, src/processors/symbol_detector.py Local
4 Link dimensions and annotations to views link_views_advanced.py Local
5 Extract title-block, note, and dimension text src/processors/ocr_engine.py Local OCR runtime
6 Validate title block, dimensions, and GD&T src/validators/langchain_validator.py Optional external LLM API
7 Apply standards rules and assemble issues src/main.py, src/validators/standards_rules.py Local
8 Generate HTML/JSON/CSV/images src/utils/report_generator.py Local filesystem

The current src/main.py orchestrator uses InferenceRunner, not DrawingLayoutAnalyzer, for its main detection stage. src/processors/layout_analyzer.py remains an alternate utility that prefers a configured local model, can call a hosted Roboflow model, and otherwise falls back to heuristics.

The upstream README describes Azure OpenAI/GPT-4 as the LLM route and local YOLO weights as the detector route. Those are upstream defaults, not the deployed Railway architecture.

Integration Policy

Use a normal upstream/fork workflow:

  1. Keep upstream pointed at sreekarrs/DraftLint.
  2. Fetch upstream changes without editing Sreekar's repository.
  3. Compare upstream/main with the Railway adapter branch.
  4. Resolve conflicts around the small adapter surface: configuration, detector provider, LLM provider, API trace UI, Railway dependencies, and Docker setup.
  5. Test the merged adapter branch before deploying.

This still requires integration analysis when upstream changes overlap adapter files, but it avoids repeatedly copying the entire repository or disturbing the friend's branch.

Current Limitations

  • The README's “production ready” wording should not be read as evidence that every model artifact is packaged or that the exact branch has been deployed on Railway.
  • Local YOLO requires available weights and enough runtime resources.
  • LLM validation is optional and depends on configured credentials and a compatible model.
  • OCR/model packages can create significant build and cold-start cost.

Open Questions

  1. Which upstream modules will continue changing most frequently?
  2. Can adapter changes be reduced further to a provider interface plus deployment files?
  3. Should tested adapter improvements be proposed upstream when they are generally useful?

Sources