Looking for critical feedback on a sanitized public demo of my AI customs classification assistant

[kalaba992]

🏷️ Discussion Type

Question

Body

Hi everyone,

I’m Edin, and I work in customs/import-export.

I’m building an AI-powered customs classification assistant for HS code determination, auditability, and anti-hallucination validation.

The main project is private, so I created a sanitized public demo repo and a live guest-only demo app for review.

Public demo repo:
https://github.com/kalaba992/Carinski-ekosistem-demo

Live demo:
https://carinski-ekosistem-demo.pages.dev

The demo contains no private data, no credentials, no Auth0, no Convex, no OpenAI, and no production infrastructure. It uses synthetic examples and illustrative classification outputs only.

I’m looking for direct, critical feedback in these lanes:

1. Architecture review
2. Security review
3. Testing strategy
4. UI/UX feedback
5. Customs-domain / legal wording review
6. Bug report

Review guide:
https://github.com/kalaba992/Carinski-ekosistem-demo/blob/main/docs/REVIEW_GUIDE.md

The questions I care about most:

• What would make this unsafe to trust?
• What would block this from becoming production-grade?
• What architectural decision should be changed early?
• What security risk would be expensive to fix later?
• What wording creates legal or professional overclaim risk?
• What test would give the most confidence?

I’m not asking anyone to build it for me. I’m looking for honest technical review and experienced eyes on weak spots.

Thank you.

Guidelines

• I have read and understood this category's guidelines before making this post.

[GlawberSantos]

Hi Edin, here's my honest technical review:

Architecture
The client-side-only approach makes sense for a demo, but in production, keeping classification logic purely on the frontend would be a serious risk — any user could inspect and manipulate the mock responses. The real classifier must live entirely server-side with no client exposure to scoring logic or GIR rule engine.

The flow ProductSelector → ChatArea → demoClassifier → ClassificationResult is clean, but I'd recommend decoupling the UI from the classification logic early using a service layer or repository pattern. This makes it much easier to swap the mock classifier for the real one without touching UI components.

Security
The demo itself is safe since it has no real backend. However, in production, the biggest risk would be prompt injection — a user submitting a product description crafted to manipulate the AI into returning a lower-duty HS code. This is expensive to fix later if the prompt architecture isn't designed with sanitization and output validation from day one.

Also, the confidence score must never be exposed as a raw number to end users without a clear disclaimer — a customs agent seeing "94% confidence" may skip the required human review, creating legal liability.

Testing
The most valuable test would be an adversarial classification test: submit products that are deliberately ambiguous between two HS chapters (e.g., a product that could be classified under chapter 39 or 73) and verify the system flags low confidence rather than picking one silently.

Legal wording
The phrase "anti-hallucination validation" on the README is an overclaim risk. No current AI system can guarantee zero hallucination — only reduce it. A safer wording would be "hallucination mitigation" or "output validation layer."

Overall
This is a well-structured demo. The audit trail concept and human-in-the-loop approach are the right instincts for a regulated domain. Focus on the prompt injection hardening early — that's the one issue that would be truly expensive to fix at scale.

[kalaba992]

Hi Glawber,

Thank you — this is exactly the kind of technical review I was hoping for. It genuinely means a lot.

I started this project from real customs/import-export workflow pain, with very little programming knowledge at the beginning, so getting concrete feedback from someone outside my own loop is extremely valuable.

Your points are fair, especially around prompt injection, confidence-score wording, and legal overclaim risk. I agree that the production classifier must stay fully server-side, with no client exposure to scoring logic, validation rules, or GIR reasoning internals.

A few notes from my side:

• The public repo is intentionally only a sanitized demo. The real classifier is backend-driven and uses stricter validation, provenance, and audit trails.
• Human review is mandatory for customs-sensitive decisions, but your point about raw confidence scores is important. I will adjust the wording so users do not interpret confidence as legal certainty.
• I agree on adversarial classification tests. Ambiguous chapter cases such as 39 vs 73 should return uncertainty or request more information instead of silently choosing one code.
• I will replace “anti-hallucination validation” wording with safer language like “hallucination mitigation” or “output validation layer.”
• I’ll convert your feedback into concrete GitHub issues so it does not get lost.

I appreciate the directness and the time you took to review it.