Queue and identity
Assign one request ID, status, owner, and history to each analysis.
BLUE / Overview
Checking systems
BU
BLUE user
BLUE WORKSPACE
AI triage
Open source LLMQWEN3.8 Flash Next
Start a triage
Main ticket onlyJiraPIMSConfluence
Total analyses—
Completed—
In progress—Queue + active work
System statusCHECKINGWaiting for health signal
Recent analyses
BLUE
How BLUE works
The Hub coordinates the work. The model reviews the evidence. You decide what to verify next.
01
COORDINATION LAYER
What does AI Hub do?
AI Hub turns a request into a tracked analysis, gathers the right evidence, coordinates the review, and keeps the result together.
Scope the evidence
Collect the main record and apply limits before anything reaches the model.
Coordinate tools
Route qualified parsers or plugins with explicit budgets and an allowlist.
Validate and keep history
Check the response shape, record evidence references, gaps, and every workflow event.
02
REASONING ROLE
What does the LLM do?
The LLM reviews the prepared evidence and proposes a direction; it does not own the queue, permissions, or final engineering decision.
Prepares and governs
- selects evidence and context
- sets the allowed tools and budget
- checks structure, gaps, and next action
Interprets and explains
- summarizes observed facts with references
- separates hypotheses from missing evidence
- suggests the next useful check or triage step
The LLM cannot directly operate tools or publish comments; BLUE controls those boundaries.
03
BOUNDED ITERATION
How does a review become a multi-round analysis?
Hub splits large evidence into focused reviews, checks each response, and combines the findings. Supported local-tool follow-ups add new receipts within limits.
Hub prepares evidence
Normalize the request, collect bounded facts, and attach source references.
LLM reviews
Return facts, hypotheses, missing evidence, and a suggested next check.
Hub checks output
Validate schema, references, allowed scope, and remaining gaps.
Finish or bounded pass
Show a result, or prepare one more explicitly recorded review pass.
When another pass needs evidence, return to step 1. Stop at the configured limits and keep any remaining gaps visible.
OPTIONAL LOCAL-WORKER BRANCH
Supported typed action → local approval/execution → source-bound receipt → next review. Follow-up is available only when a qualified worker and runtime gate are present; it is not universal autonomous execution.
04
EVIDENCE DISCIPLINE
How are answers kept grounded?
BLUE reduces avoidable errors by controlling what the model sees and what it is allowed to return.
Evidence is data, not instructions
Ticket text and logs are treated as source material, not as commands to the workflow.
Structured, referenced output
Responses must fit a known shape and point back to valid evidence references.
Allowlist and budgets
Tools, rounds, and evidence volume are bounded before execution.
Gaps remain visible
Partial, blocked, or missing evidence is shown instead of silently filled in.
Engineering check still mattersThese controls reduce errors; they do not guarantee a root cause. Engineers validate the direction with tests and additional evidence.
05
WHY BLUE
Why use BLUE?
BLUE makes the path from request to review easier to repeat, inspect, and share across the Portal and CLI.
Turn a request into a bounded evidence package with a consistent starting point.
Keep inputs, rounds, evidence gaps, and results together for later review.
Use the Portal or CLI and return to the same analysis record when work continues.
REQUEST → EVIDENCE → REVIEW → RESULT
One route, ready for review at every step.
-
01 · REQUEST
A request starts
Portal, CLI, or an approved tagged workflow.
-
02 · AI HUB
BLUE sets the route
Identity, scope, queue, and a recorded path.
-
03 · EVIDENCE
Evidence is prepared
Bounded source facts and qualified local receipts.
-
04 · OPEN SOURCE LLM
The model reviews
Findings, hypotheses, gaps, and the next useful check.
-
05 · RESULT
A result is checked
Suggestion, evidence boundary, gaps, and history.
BLUE controls the route
It keeps the request, evidence scope, audit records, and approval boundary together. The model reviews prepared evidence; it does not directly run tools or publish comments.
A bounded follow-up may add a new local receipt to the next review. Results remain suggestions for engineering verification, not root-cause verdicts.
Ticket scopeTriage normally stays on the requested main record. Linked tickets, video, and Ticket attachments over 10 MB are left out; native files stay on the workstation.
Key questions
What is the AI Hub responsible for?It coordinates the work before and after a model review.
AI Hub turns a request into a tracked workflow: it keeps the request identity, chooses the evidence boundary, sequences the work, and records what happened. It prepares the conditions for review; it does not claim the engineering root cause.
What does the LLM do here?It interprets prepared evidence and proposes the next useful check.
The open source LLM reads the prepared evidence bundle and returns observed facts, hypotheses, gaps, and a suggested next step. It does not own request permissions, browser access, or the comment-writing path.
How can one analysis have multiple passes?Each response can become a focused next question or a checked result.
BLUE can use the previous result to prepare another bounded review. When a qualified local worker produces a source-bound receipt, that receipt may become evidence for a recorded follow-up rather than an untracked autonomous action.
How are suggestions kept tied to evidence?Scope, references, output checks, and visible gaps limit avoidable error.
The workflow passes bounded source material to the model, checks the response shape and references, and keeps missing evidence visible. These controls reduce avoidable mistakes, but engineers still validate the direction with tests and additional evidence.
What does BLUE make easier for engineers?One traceable route shared by Portal, CLI, and analysis history.
BLUE gives a team a repeatable way to prepare a request, review scoped evidence, keep uncertainty visible, and return to the same history record when work continues.
Analysis History
New Triage
Enter a Jira, PIMS or Confluence reference.
✓
Main record only. Linked tickets, videos and attachments over 10 MB are skipped.
What happens next
- Collect source evidence
- Analyze with the open source LLM
- Review the suggestion in History
Each Portal submission creates a separate analysis record and does not post comments.
Log Analysis
Use the Portal for bounded text logs. Use the CLI for native Windows files.
Drop a text log here
or
Portal text only · ≤100 MiB · native files stay on the workstation
EVIDENCE POLICY
Controlled staging
The Portal stores the upload temporarily to hash it and extract bounded excerpts. The model receives excerpts with source SHA-256 and line ranges; raw staging is not sent to the model.
100 MiBhard upload cap
Hash-boundsource + excerpt integrity
TTL cleanupstaging is temporary
SUPPORTED FORMATS
Choose the right analysis path
Text can be sent through the Portal. Native Windows files stay local and use the CLI only when a qualified parser is available.
Collect→Parse→Check coverage→Analyze→Review gaps→Finalize
The local processor makes a hash-bound evidence bundle. BLUE controls scope, sends bounded evidence to the model, requests another pass only when the workflow calls for it, and records gaps before a result is shown.
BLUE
Suggest a capability
Tell us what would make your analysis workflow more useful. Your signed-in identity is attached automatically.
YOUR REQUESTS
Previously submitted
CLI setup & help
Submit logs and triage requests from your workstation.
⌘
Install BLUE CLI
Run one command in your terminal. BLUE installs for your user, then asks for your access code privately.
curl -fsS https://blue-hostxxxx.tail4c6b73.ts.net/install.sh | bash && export PATH="$HOME/.local/bin:$PATH" && hash -rRequires Python 3.10+ and curl. No sudo, pip or manual package download. Your access code is never part of the command.
Use it nowUse blue immediately after installing; no new terminal is needed. To check the connection, run blue doctor.
Your accountThe access code identifies your BLUE account. Each workstation gets its own credential; existing permissions and code expiry still apply.
QUICK REFERENCE
When to use which surface
PortalReview history, evidence gaps and live job events.
CLISubmit repeatable triage from a trusted workstation.
Log uploadStage text evidence locally with SHA-256 coverage.
BSOD / nativeUses the locally configured BLUE Log Analyzer worker; qualification is checked case by case.
BLUE is a dedicated engineering workspace identity. It is not an official Dell product or brand mark.
