Pixel Character System

The items:

• sessions
• agents
• users and power users
• MCP servers
• models
• API keys
• endpoints
• tools and skills
• repos and files
• secondary calls

These objects are technically precise, but many of them blur together visually: agents, models, MCP servers, endpoints, and tools can all look like "some machine." A character system gives each entity a memorable role, silhouette, and relationship to the others.

This cycle turns the vocabulary into art direction that a pixel character artist can execute.

The system should help users recognize the key inventory entities, understand their relationships, and follow the security story of an AI agent session without relying only on labels, tables, or abstract diagrams.

1. Define the entity cast and visual roles.
2. Establish silhouette, prop, and scale guidance for pixel art.
3. Define state overlays for security meaning: unknown, new, unusual, sensitive, concentrated, unstable, exposed, low confidence, active, ended, and error.
4. Describe relationship rules for session evidence chains and topology scenes.
5. Produce a handoff-ready design brief for a pixel character artist.

Out of scope:

• building the final pixel assets
• choosing final sprite dimensions for production implementation
• integrating artwork into Nuxt pages
• replacing existing wireframe or mockup icon systems
• creating a full brand illustration system beyond the AI visibility inventory domain

1. Cycle definition
2. Pixel character design brief
3. Entity cast with definitions, roles, visual cues, and relationship rules
4. Production deliverable checklist for the artist
5. Optional follow-up asset inventory once sketches or sprites exist

Pending. This cycle begins with the character-art handoff brief and should evolve as artist feedback clarifies which metaphors survive at pixel scale.

The art should behave like visual grammar

• Session: What story are we following?
• User: Who is associated with it?
• Endpoint: Where did it run?
• Agent: What software acted?
• Model: What reasoning engine powered it?
• API Key: What credential authorized it?
• MCP Server: What capability station expanded reach?
• Tool: What action was taken?
• Skill: What playbook shaped behavior?
• Repo / File: What material was touched?
• Secondary Call: What boundary was crossed?
• Power User: Where is capability concentrated?

• design-brief.md — first-pass artist handoff brief

• .claude/skills/visualization-sketches.md — use for topology scenes, session evidence chains, boundary-crossing diagrams, state overlays, and qmap/qflow/qpixel-inspired composition.
• .claude/skills/wire-components.md — use if this cycle produces lo-fi wireframe pages to review the character system inside dashboards, maps, or inventory cards.
• .claude/skills/ux-components.md — use if character assets are tested in higher-fidelity mockups with real Qpoint components.
• imagegen — optional Codex skill for generating raster exploration sheets, sprite references, or visual variants before handing final direction to the pixel artist.

c11 is successful if the brief lets an artist create recognizable pixel assets that:

• distinguish agents from models, MCP servers, endpoints, and tools
• preserve Qpoint's security and infrastructure seriousness
• work at small dashboard sizes
• support common states without requiring new characters for every condition
• explain a complete session evidence chain in one grouped scene
• make power users feel high-reach rather than suspicious by default

• Cycle created
• First-pass design brief drafted
• Artist feedback captured
• Entity sprite checklist finalized
• First sketch pass reviewed
• Asset integration targets identified