CMS workflow
Connected the AI check to a deliberate admin action on an individual ticket rather than running it automatically on every report.
AI Pipelines
Klinik Hoaks AI Fact Checker CMS Integration
An internal CMS assistant that gathers web evidence and returns a structured fact check for admin review.
- Client
- Dinas Kominfo Provinsi Jawa Timur
- Role
- AI Engineer
- Year
- 2025–2026
- Status
- On hold, not deployed
Klinik Hoaks CMS displaying a high confidence Fakta result with a suggested action, detailed explanation, and external source references
Overview
Web evidence inside the admin workflow
Klinik Hoaks AI Fact Checker was developed as an internal tool for the Klinik Hoaks CMS. An administrator selects a report, runs the Cek Fakta AI action, and reviews a result that includes a verdict, confidence level, suggested action, explanation, and external references.
The LangFlow pipeline uses two Amazon Nova stages. The first prepares a focused Google query from the claim, optional source URL, and scraped article content. The second compares the claim with that source content and the Google results, then returns Fakta, Hoaks, or Belum Terverifikasi in a structured JSON response.
I developed the AI checking flow and connected it to the CMS ticket action. My work covered source extraction, search query generation, Google Search integration, evidence synthesis, output parsing, and failure handling. The available evidence demonstrates the integrated workflow, but it does not include benchmark accuracy, calibrated confidence, latency, or a human evaluation study.
Technology stack
AI and orchestration
- LangFlow
- Amazon Nova
- Prompt Design
Evidence acquisition
- Google Search API
- URL Scraping
- Jina.ai Reader
Delivery and safeguards
- Structured JSON
- Safe Result Parser
- CMS Integration
ProblemResearch began outside the ticket workflow
A Klinik Hoaks administrator needs external references before deciding how to handle a submitted claim. That work requires reading the report, finding independent sources, comparing their evidence, and recording an explanation that another reviewer can inspect.
The integration had to support that investigation without hiding the evidence or replacing the administrator. It also needed an explicit uncertain state for cases where the available sources were too weak or inconsistent to support Fakta or Hoaks.
Scattered evidence
Claims may arrive with a source link, a vague description, both, or neither in a useful form.
Review remains human
The AI result supplies references and an initial assessment inside the CMS; the administrator still reviews the evidence.
ContributionBuilt the evidence and verification pipeline
I developed the two stage LangFlow workflow and integrated it with the Cek Fakta AI action in the CMS. The first stage turns the ticket claim and any usable article context into a focused search query. The second stage compares the claim with retrieved evidence and produces a structured result for the admin interface.
I also implemented URL validation, blocked page detection, Jina.ai Reader fallback, Google result formatting, JSON repair, and a manual investigation fallback. These paths prevent a failed scrape or malformed model response from being treated as a confident verdict.
Evidence collection
Combined the ticket claim, optional article content, and independent Google results before verification.
Structured delivery
Returned verdict, confidence, explanation, references, recommendation, and suggested admin action as validated JSON.
ArchitectureTwo model stages with evidence in between
The CMS sends the claim and an optional source link to LangFlow. When a link is present, the URL processor validates it, limits downloaded content, detects blocked or error pages, and can retry through Jina.ai Reader. Social media domains are treated as sources that may not be directly accessible to the scraper.
The query generator keeps useful entities such as names, places, dates, and events while removing request phrases. It can use article content when the claim is vague and can exclude the submitted domain from Google Search so the evidence does not merely repeat the original source.
The verification prompt receives the claim, scraped source content, and parsed Google results. Amazon Nova produces a structured result, then a defensive parser removes code fences, repairs common JSON mistakes, and sends unparseable cases to manual investigation instead of forcing a verdict.
Prepare the ticket
Admin action
Run Cek Fakta AI for one selected ticket
Claim and source link
Read the report text and optional submitted URL
URL processing
Validate, scrape, and use Jina.ai Reader when needed
Collect evidence
Generate a search query
Keep the entities and remove request noise
Search Google
Request four external result candidates
Parse safely
Format titles, snippets, and links for verification
Return a reviewable result
Compare the evidence
Give the claim, source content, and search results to Amazon Nova
Validate the JSON
Repair common formatting errors or request manual review
Display in the CMS
Show verdict, confidence, explanation, sources, and recommendation
Search before verification
The model does not classify the claim in isolation. It first gathers external evidence through a separate query generation stage.
Failure produces review
If the output remains invalid after repair, the system requests manual investigation rather than inventing a structured result.
ResultsA reviewable AI result inside the CMS
2
Amazon Nova stages
query generation and fact verification
3
possible verdict states
Fakta, Hoaks, or Belum Terverifikasi
4
Google results requested
per search in the documented LangFlow configuration
Manual
fallback review path
used when the response cannot be parsed safely
The implemented CMS flow adds Cek Fakta AI to the ticket action menu and returns the analysis in the same interface. The representative result shows a Fakta verdict with high confidence, a suggested action, a detailed explanation, and links to the sources used.
The output schema also supports Hoaks and Belum Terverifikasi, search relevance, a recommendation to close or keep the ticket open, and a suggested next action for the administrator. When the parser cannot recover valid JSON, the workflow returns a manual investigation fallback.
The supplied project evidence demonstrates a working integration in the project environment, but the system was not deployed to production. It does not include a benchmark dataset, verdict accuracy, confidence calibration, hallucination rate, latency, source quality score, or human evaluation.
Evidence stays visible
The result includes source links and an explanation so the administrator can inspect what supported the verdict.
Uncertainty has a state
Belum Terverifikasi gives the workflow an explicit outcome when the available evidence is insufficient.
The evidence is qualitative
The available materials prove CMS integration and output structure, but do not establish accuracy or time saved.
LearningsWhat the implementation required
Search quality starts with the claim
Vague reports need source content or stronger entity extraction before Google Search can return useful evidence.
References belong in the interface
A verdict alone gives an administrator little to review. The CMS result needs the explanation, source links, and recommended next action together.
Model output needs defensive parsing
Code fences, trailing commas, and mixed text can break a valid analysis at the delivery step. Repair rules and a manual fallback keep those failures visible.
Next project
BISINDO Alphabet Segmentation
A 2025 computer vision study comparing segmentation quality, inference speed, and recognition errors in two lightweight YOLOv8 models.