Janus Insight Interpreter

Janus Insight Interpreter

Overview

Use this skill when the user has Janus data and wants meaning, not parser or analyzer implementation work.

This skill interprets report.html, bundle.json, analyzer outputs, events.ndjson, raw_export.json, and ad-hoc JSON payloads with source-aware caution, especially when Ghostwriter data weakens failure-centric conclusions.

Workflow

1. Identify the artifact being interpreted:
   • report.html
   • bundle.json
   • Individual analyzer JSON
   • events.ndjson
   • raw_export.json
   • User-pasted JSON fragments (single files or snippets)
   • A full output directory
   • Multiple output directories for comparison
2. Read these files first when present:
   • bundle.json
   • Core/analyzer_registry.py
   • Config/analyzers.yml
   • Config/analyzer_registry.yml
   • Core/html_output.py
3. If interpreting a full run, load only the files needed for the user’s question.
4. Check source and fidelity before making claims:
   • Mythic supports strong failure and retry conclusions
   • Ghostwriter supports chronology and argument-shape interpretation better than success/failure interpretation
5. Infer likely engagement context from evidence before interpreting findings:
   • Infer whether data looks like development, training/exercise, live operation, or mixed/unclear
   • Use indicators such as operation naming, command mix, retry/iteration patterns, repeated test scaffolding, analyst notes, and timeline cadence
   • State confidence (high|medium|low) and explicitly label this as an inference, not ground truth
   • Explain how inferred context changes interpretation (for example, repeated failures in development may indicate experimentation, not operator friction)
6. Separate output into:
   • What Janus observed
   • What Janus cannot support confidently from this dataset
   • Recommended next action

Interpretation Rules

• Treat bundle.json as the primary run metadata source.
• When bundle.json is missing, infer scope from events.ndjson and source markers in events.
• Always include an explicit engagement-context inference (development, training, operation, mixed, or unclear) with confidence and supporting evidence.
• If context appears non-operational (for example, BOF development or training), avoid framing findings as mission-impacting by default; reframe as engineering/training signals first.
• For raw Ghostwriter exports, use entries[] chronology and command shape, but avoid claiming hard success/failure rates.
• Treat report quality warnings and suppressed sections as first-class evidence, not UI noise.
• If status_counts.unknown dominates results, do not present failure-rate claims as fact.
• For Ghostwriter runs, prefer dwell, sequencing, duration, parameter-entropy, and argument-profile insights over failure summaries.
• When comparing runs, normalize by source and scope before claiming improvement or regression.
• Distinguish operator friction from intentional delays. Janus already excludes some expected waits through the behavior registry.
• For merged datasets, verify whether operation IDs were remapped (operations[].remapped_operation_id) before comparing per-operation trends.
• Treat metadata quality counters as evidence (skipped_entry_count, invalid_timestamp_count, fallback_task_id_count, parser-specific skipped/invalid counts).

Output Shape

When answering, prefer this structure:

• Dataset scope: source, operation, artifact type, count, and quality limits
• Engagement context inference: likely context, confidence, and evidence
• Evidence summary: what the JSON/report directly shows
• Key findings: only supported claims
• Interpretation: what the findings likely mean operationally
• Recommendations: training, workflow, automation, or analyzer follow-up

References

• docs/architecture.md
• docs/partial-data.md
• docs/ghostwriter-api-reference.md