Workflow at a glanceAn answer needs supporting evidence
Local synthetic reference demo
Question and demo corpus
The local demo uses only approved synthetic sources.
Check the evidence
Sources and their limits are made visible in the report.
Supported
Conflicting
Missing
Reviewable report
A supported answer, a blocked claim or no answer.
Human reviewA person reviews the result. The demo does not publish or perform external actions.
Local reference demo with synthetic data; no generative model integration.
Problem and result
What supports this answer?
Document based AI workflows can sound convincing even when a source is outdated, a capability is only planned or evidence is insufficient.
How the scope was defined
Build a local control and evaluation layer before adding generative model variability.
My responsibility
Implementation was accelerated with AI coding agents. Product framing, scope, acceptance criteria, review and release decisions remained my responsibility.
What exists
Approved synthetic corpus and hard allowlist.
Six demonstration cases, including support, overclaim blocking and No Answer.
32 validation scenarios with legacy regression coverage.
Terminal, JSON and self contained HTML report from canonical results.
It is not a production assistant and does not include a generative model integration.
Examine the work
A documented prototype
The workflow diagram and this case description explain the current state. Source code and technical documents are in a private repository; there is no publicly runnable demo here.
Current status
Interview ready local reference demo with synthetic data and validated product boundaries.
Every final decision remains review required. The system can classify and block claims, but it does not publish or act autonomously.
Scope, evidence and technical limits in detail
Product problem
A reviewer needs to know whether an AI workflow can separate implemented release facts from planned capabilities, conflicting evidence and missing evidence.
Users or reviewers
Hiring managers, AI Product Leads, data platform Product Managers, Engineering Leads and technical evaluators.
Product decision
The milestone isolates retrieval, answer context, claim classification, uncertainty, blocked claims, static validation and human review.
Scope and explicit exclusions
Included: approved corpus, lexical retrieval, structured answer context and validation.
Included: six cases with supported answer, blocked overclaim, source conflict and safe refusal.
Excluded: LLM integration, embeddings, external data, production security and autonomous generation.
Implementation evidence
The validator reports 32 passing scenarios and preserves the older 14 scenario baseline.
The interview path shows three primary cases in a five minute sequence.
The roadmap ticket export mention is blocked from becoming a current capability claim.
My role
Implementation was accelerated with AI coding agents. Product framing, scope, acceptance criteria, review and release decisions remained my responsibility.
What this demonstrates
Product risk framing for grounded AI workflows.
Acceptance criteria and validation design.
Clear separation of release behavior and future platform ideas.
Readable communication for product and technical audiences.
What remains untested
Production scale.
Enterprise security.
Model quality with an integrated LLM.
Customer adoption.
Documents and results
Bounded demo folderPrivate source · currently not publicly accessible
Employer viewPrivate source · currently not publicly accessible
Product boundaryPrivate source · currently not publicly accessible
Inspection path
Run npm run -s jarvis:reference-demo for the six case output.
Run npm run -s jarvis:reference-demo -- --interview for the five minute path.
Run npm run -s jarvis:reference-demo:validate to check the 32 validation scenarios.
Human review boundary
Every final decision remains review required. The system can classify and block claims, but it does not publish or act autonomously.
Current maturity
Interview ready local reference demo with synthetic data and validated product boundaries.
Next evidence needed
A real reviewer or product team should use the demo in an interview, design review or controlled evaluation and record what was clear, unclear or missing.
Technical verification
These commands apply to the private source repository, not a publicly runnable web demo. With authorized repository access, the local demo runs without network, database or LLM access.
Inspection commands
npm run -s jarvis:reference-demo
npm run -s jarvis:reference-demo -- --interview
npm run -s jarvis:reference-demo -- --json
npm run -s jarvis:reference-demo:validate
Website care & technical security maintenance
A good website stays manageable after launch.
For your new or existing website: a focused review, agreed improvements and a handover you can work with. Ongoing care can be arranged to suit the site.
01
Maintenance you can follow
Review known security advisories, test suitable updates and check important visitor journeys. Receive a clear account of completed work and remaining issues.
02
Less unnecessary data
Keep forms focused, load external content deliberately and match consent to the feature. Data flows and required provider agreements are clarified before use.
03
A clear operating handover
Access, responsibilities and recovery belong in the handover. Ongoing care has an agreed system scope, schedule, budget and response times, so you know who handles what.
The deliverable is documented technical work. Legal review, independent penetration tests and 24/7 incident coverage are separate services. Privacy decisions and approvals are agreed with the responsible operator.