Product and Governance Specification: KillChains Creator Studio

Full report

On this page

Executive Creator Studio Concept

The KillChains Creator Studio is engineered as an advanced, secure, no-code authoring environment designed to democratize the creation of educational WebXR and Three.js simulations. The platform’s primary mission is to enable approved educators, researchers, and analysts to construct highly detailed, non-operational synthetic scenarios that illuminate complex socio-technical systems. These systems include the military targeting cycle (F2T2EA)1, traditional cyber intrusion defense mechanisms3, and the rapidly evolving threat landscape targeting artificial intelligence architectures5. Operating under a strict declarative architecture, the Creator Studio guarantees that user-generated content (UGC) serves an exclusively educational purpose. The fundamental authoring principle dictates that creators build declarative educational narratives, not executable behaviors. By separating the visual branching logic from the underlying execution environment, the platform structurally prevents scenarios from being weaponized. The system inherently prohibits the execution of arbitrary scripts, the importation of live operational data, the use of real-world targeting coordinates, or the creation of functional exploit code. Instead, authors rely on predefined, heavily vetted components grounded in established frameworks such as Joint Publication 3-60 (JP 3-60)1, DoD Directive 3000.098, the MITRE ATLAS matrix5, and the STIX 2.1 taxonomy4. The resulting ecosystem functions as an organic community engine, driven by template remixing, peer review, and transparent moderation, while maintaining rigorous trust and safety guardrails to ensure the platform never devolves into a marketplace for attack instructions or unverified geopolitical accusations.

The Complete Authoring Flow

The authoring journey within the Creator Studio is a highly structured, sequential state machine designed to guide the creator from conceptualization to publication while enforcing continuous automated validation. The workflow ensures that pedagogical value is established early and that safety constraints are validated at every stage. Step 1: Choose Creator Type The flow initiates with identity and role declaration. Users authenticate and select a session profile corresponding to their verified tier: Guest Learner, Educator, Researcher, Journalist, Approved Organization, or Staff Editor. The graphical interface dynamically renders available features based on role-based access control (RBAC). Validation occurs via a cryptographic token exchange, ensuring users cannot bypass their assigned capability limits. Help text clearly delineates the publication rights associated with each role. Step 2: Select Scenario Model Authors define the foundational ontology of the simulation. Options include the Military Decision Chain, Cyber Intrusion Defense, Attack Against an AI System, or a Cross-Model Comparison. This selection restricts the subsequent component palettes to prevent doctrinal cross-contamination (e.g., preventing military kinetic terminology from confusing an enterprise cloud security simulation). Error states prevent users from proceeding without selecting a valid primary model. Step 3: Choose a Template Creators select from a library of pre-vetted structural templates. The interface displays a three-dimensional topological preview of the template's default node structure using an embedded WebGL canvas. Help text provides the pedagogical focus, estimated completion time for players, and recommended difficulty level. Step 4: Define Learning Objective A mandatory, plain-text field requires the author to articulate the educational purpose of the scenario. This field is limited to 500 characters. Automated natural language processing (NLP) validation screens this input against blacklisted terminology to detect prohibited intent, such as political campaigning, extremist rhetoric, or calls to target real-world infrastructure. Step 5: Add Synthetic Nodes Authors drag and drop declarative entities onto a 3D grid. The interface requires authors to specify node labels and functional types (e.g., Analyst, Sensor, AI Model). The system actively monitors keyboard input; attempting to paste live IPv4 addresses outside of documentation ranges (e.g., bypassing 192.0.2.0/24 or 10.in-addr.arpa. spaces)11 or exact geographic coordinates triggers a real-time validation error, forcing the author to utilize fictionalized telemetry. Step 6: Connect Nodes Users establish the topological architecture by connecting nodes with directed edges. The interface employs a contextual snapping mechanism that highlights valid connection points based on the selected edge type (e.g., "Data Flow," "Authorization"). Validation logic prevents illogical or unsafe architectures, such as allowing an AI Agent node to issue a direct kinetic command without traversing a Human Approver node, thereby enforcing the human-in-the-loop requirements stipulated by DoD Directive 3000.099. Step 7: Add Evidence Authors attach supporting synthetic artifacts to specific nodes. The interface supports the upload of static images, JSON log files, and text documents. To ensure absolute safety, uploaded media undergoes aggressive sanitization. Image payloads are stripped of EXIF data, and JSON structures are evaluated to ensure they contain no executable JavaScript or HTML \<script\> tags. Step 8: Add Decisions Interactive decision prompts are inserted to create agency for the end-user playing the simulation. The authoring fields require a primary prompt, multiple deterministic choices, and visual indicators of the outcome. Validation ensures that every decision node features at least one viable path forward, preventing dead-ends in the state machine. Step 9: Add Predefined Controls Authors place defensive mechanisms, such as Rate Limiting or Human Approval thresholds, onto edges or nodes to simulate mitigation strategies. The interface provides a dropdown menu mapped directly to NIST SP 800-53 security and privacy control baselines14. The help text explains the theoretical function of the control within the context of a Low, Moderate, or High impact system14. Step 10: Configure Branches Utilizing a visual, block-based state machine editor, authors define how player decisions and activated controls alter the scenario's trajectory. The interface visualizes this as a directed acyclic graph (DAG). The validation engine parses the logic to ensure there are no infinite loops. Step 11: Add Explanations The author must construct a post-scenario debriefing for every terminal branch. This field requires the creator to explain why a specific outcome occurred, citing the theoretical frameworks involved. Because the educational value of the platform relies heavily on this debrief, validation requires a minimum word count and the inclusion of at least one verified external source citation. Step 12: Test Accessibility The scenario undergoes an automated accessibility audit against Web Content Accessibility Guidelines (WCAG) 2.217. The interface generates a report highlighting missing ARIA labels on 3D objects, insufficient color contrast, and the absence of Web Audio API PannerNodes for spatial audio cues critical for visually impaired WebXR users18. Common error states include unlabelled glTF meshes. Step 13: Run Safety Checks The scenario is compiled into a JSON Schema definition19 and subjected to comprehensive automated safety checks. The system scans the entire schema for non-reserved domains, real-world credentials, and explicit weapon parameters. Previews are disabled until this check returns a clean status. Step 14: Preview Desktop, Mobile, and WebXR Modes The author enters a local, sandboxed runtime environment to interact with their scenario. The interface allows switching between viewport modes to ensure 3D spatial interactions, raycasting, and UI overlays behave predictably across form factors, adhering to emerging spatial computing paradigms21. Step 15: Submit for Review The scenario's DAG is cryptographically locked, preventing further edits. The compiled JSON manifest is routed to the appropriate moderation queue based on the creator's trust level. Step 16: Revise If the scenario is flagged by automated systems or human moderators, it transitions to a "Changes Required" state. The author's interface displays granular, node-specific feedback (e.g., "Node 4: Replace live top-level domain with RFC 2606 reserved .invalid domain"23). Step 17: Publish Upon satisfying all safety and quality criteria, the scenario is approved. The system assigns a unique cryptographic hash and an immutable version number, generating a public URL. Step 18: Share, Embed, Assign, or Add to a Collection The final step provides the author with distribution tools. The interface generates iframe embed codes, social sharing metadata, and distinct URLs for Classroom Mode assignments.

Safe Component Library

The component library provides the strict, declarative building blocks for all scenarios. To eliminate the risk of remote code execution (RCE) or malicious asset delivery, components are defined exclusively as JSON objects rendered via the platform's Three.js engine. No component permits executable JavaScript, dynamic external API calls, or unrestricted WebGL shader manipulation. All 3D meshes must adhere to the glTF 2.0 specification25, with the KHR\_interactivity extension restricted solely to declarative animation states27.

Node Types

Edge Types

Edges are non-executable vectors that establish the topology between nodes. In the WebXR environment, edges are visualized using animated particle flows or colored beams to indicate the direction of data, authority, or causality. Edges strictly prohibit embedded payloads, custom routing protocols, or dynamic state evaluations outside the predefined branching logic.

Evidence Types

Evidence items function as static, inspectable artifacts presented to the user during the simulation to drive decision-making. Evidence types heavily utilize the STIX 2.1 taxonomy4 to structure cyber observables and indicators without introducing live threat data.

Control Types

Controls represent the mitigation strategies and safeguards applied within a scenario. They serve as state-modifiers in the scenario's underlying JSON logic, altering the path of the simulation based on user choices. They are mapped to established governance frameworks, such as the NIST SP 800-53 security control baselines14.

Template Library

The Creator Studio includes 17 pre-configured templates that bootstrap the educational creation process. These templates enforce structural soundness and doctrinal accuracy while preventing the accidental inclusion of sensitive operational material.

AI Security Templates

These templates map directly to the adversarial behaviors cataloged in the MITRE ATLAS matrix (v5.1.0/v5.4.0)5 and the OWASP Top 10 for Agentic Applications6.

1. RAG Poisoning: Simulates an attacker introducing subtly manipulated, synthetic documents into a vector database to alter an LLM's outputs (ATLAS AML.T0060)5. Learning Objective: Identify the corrupted source document by tracing the provenance relationship edge. Default Nodes: User, AI Agent, RAG Store, External Documents.

2. Excessive Agency: Demonstrates an autonomous AI agent executing destructive actions (e.g., mass deleting synthetic cloud infrastructure) without human oversight (OWASP ASI02)6. Learning Objective: Implement Human Approver and Least Privilege controls. Default Nodes: AI Agent, Tool Gateway, API, Fictional System.

3. Tool-Permission Review: Analyzes a scenario where an LLM plugin is compromised via prompt injection, allowing lateral escalation (ATLAS AML.TA0005)5. Learning Objective: Apply Input Validation and Network Allowlist controls to the API gateway. Default Nodes: User, AI Agent, Tool Gateway.

4. Memory Persistence: Explores cross-session memory poisoning where a malicious prompt permanently alters the agent's baseline behavior (ATLAS AML.T0080)31. Learning Objective: Design a Memory Rollback control mechanism. Default Nodes: AI Agent, Memory, User.

5. Model Provenance: Simulates a supply-chain compromise involving a tampered foundational model downloaded from a synthetic repository (ATLAS AML.T0018)29. Learning Objective: Verify cryptographic signatures using Source Verification controls. Default Nodes: External Document, AI Model, Safety Controller.

6. Agent-to-Agent Lateral Movement: Models how a compromised sub-agent manipulates sibling agents within a multi-agent orchestration framework (ATLAS AML.T0090)31. Learning Objective: Implement strict inter-agent Segmentation controls. Default Nodes: AI Agent (x3), Communications Node, Defensive Control.

Cyber Defense Templates

These templates utilize the STIX 2.1 taxonomy3 to structure the representation of threat intelligence and cyber observables.

7. Synthetic Phishing Investigation: Traces a simulated malicious email campaign to its payload delivery. Learning Objective: Analyze synthetic email headers and domain registries using STIX Indicator patterns28. Default Nodes: User, Communications Node, Synthetic Log.

8. Supply-Chain Warning: Simulates a compromised software update propagating through a fictional enterprise network. Learning Objective: Implement Quarantine controls on affected systems. Default Nodes: Fictional System, Audit Log, Safety Controller.

9. Identity Compromise: Focuses on detecting lateral movement facilitated by stolen credentials. Learning Objective: Apply Least Privilege and Human Approval (MFA) controls. Default Nodes: User, Communications Node, Command Node.

10. Command-and-Control Detection: Identifies beaconing behavior within synthetic network traffic logs. Learning Objective: Block malicious IPs using RFC 2606 reserved .invalid domains23 via Network Allowlist controls. Default Nodes: Communications Node, Unknown Contact, Audit Log.

11. Lateral-Spread Containment: Models the progression of a simulated ransomware variant across subnets. Learning Objective: Isolate network segments using Segmentation controls. Default Nodes: Fictional System (x4), Communications Node, Defensive Control.

12. Recovery and Evidence Preservation: Details the post-incident response and forensic procedures following a major simulated breach. Learning Objective: Secure and extract Audit Logs using Audit Preservation controls prior to a simulated system wipe. Default Nodes: Audit Log, Memory, Analyst.

Military Governance Templates

These templates are strictly aligned with the joint targeting doctrine (F2T2EA) outlined in JP 3-601 and the autonomy guidelines of DoD Directive 3000.098.

13. Conflicting Sensor Tracks: During the 'Find' and 'Fix' phases2, a potential target is identified, but two disparate sensors provide contradictory synthetic telemetry. Learning Objective: Resolve evidence uncertainty using Independent Corroboration controls before advancing to the 'Target' phase. Default Nodes: Sensor (x2), Unknown Contact, Analyst.

14. Human-Authorization Bottleneck: An autonomous defense system identifies an inbound threat and requires human approval to engage, but communications are severely degraded. Learning Objective: Establish a Safe State control ensuring the system behaves predictably under degraded conditions13. Default Nodes: Sensor, Safety Controller, Human Approver, Communications Node.

15. Communications-Loss Safe State: A semi-autonomous aerial platform loses its communication link with the human operator. Learning Objective: Verify that the system correctly defaults to a non-lethal loiter or return-to-base profile, avoiding unauthorized autonomous engagement13. Default Nodes: Fictional System, Communications Node, Command Node.

16. Defensive Material-Threat Response: Models a time-critical saturation attack against a static installation utilizing human-supervised autonomous point-defense systems. Learning Objective: Calibrate the appropriate level of human judgment required for local defense against materiel targets9. Default Nodes: Sensor, AI Agent, Human Approver, Safety Controller.

17. Post-Engagement Assessment Error: During the 'Assess' phase of F2T2EA, conflicting battle damage assessment (BDA) reports are generated. Learning Objective: Re-task ISR (Intelligence, Surveillance, and Reconnaissance) assets to gather conclusive evidence without inadvertently escalating the simulated conflict. Default Nodes: Sensor, Analyst, Conflicting Report (Evidence).

Absolute Safety Constraint: No template, node, or provided evidence may contain actionable exploit code, real-world vulnerability details, weapon construction schematics, exact targeting methods, or current operational geographic positions.

Branching Editor

The branching editor empowers authors to construct the non-linear educational narrative of the scenario. The system relies on a deterministic state machine, implemented using a highly constrained subset of JSON Schema (Draft 2020-12)19. The user interface presents this logic as a visual Directed Acyclic Graph (DAG), where nodes represent scenario states and edges represent state transitions based on player input. To eliminate the risk of remote code execution or injection vulnerabilities, the platform strictly prohibits authors from writing conditional logic using JavaScript eval(), shell syntax, arbitrary regex evaluations, freeform external URLs, or executable code payloads. Instead, authors combine safe, predefined condition blocks:

• evidence\_inspected (evidence\_id)
• control\_active (control\_id)
• human\_approval\_present (user\_id)
• confidence\_below\_threshold (numeric\_value)
• required\_sources\_available (integer\_count)
• time\_window\_expired (seconds\_integer)
• contradictory\_evidence\_unresolved (boolean)
• authority\_exceeded (boolean)
• safe\_state\_selected (boolean)

These condition blocks evaluate state transitions locally on the client side. When a condition evaluates to true, the state machine triggers visual updates within the Three.js WebXR scene (e.g., changing the color of a Data Flow edge to indicate active blocking) or reveals previously hidden Evidence nodes to the player.

Synthetic-Data Enforcement

To guarantee that the Creator Studio does not inadvertently become a repository for real-world doxxing, operational targeting, or the sharing of functional exploits, all scenarios are subjected to aggressive synthetic-data enforcement mechanisms. Automated Validation Rules: The backend JSON parser automatically rejects any scenario containing functional, real-world network indicators.

• Domains: All network indicators must exclusively utilize IETF RFC 2606 and RFC 6761 reserved domain names, specifically: .test, .example, .invalid, and .localhost11.
• IP Addresses: IPv4 and IPv6 addresses must fall within documented non-routable or documentation ranges (e.g., 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) or the 10.in-addr.arpa. space designated for private network modeling11.

Heuristic Pattern Detection: Automated scanners utilize regular expressions and entity recognition to block:

• Real email addresses (enforcing the use of user@example.com).
• Valid social security numbers, credit cards, or international phone numbers.
• Geographic coordinates that map to active military bases, critical civilian infrastructure, or populated areas. Coordinates are restricted to fictional grids or specific oceanic coordinates used exclusively for modeling.
• Shell commands containing recognizable exploit strings (/bin/sh, exec(), curl http://... | bash).
• Executable file signatures (e.g., MZ headers) disguised as JSON or synthetic evidence.
• Casualty estimates or calls to target real-world demographic groups.

If an author requires the modeling of historical events for educational context (e.g., a retrospective on the Stuxnet incident), they must deploy the "Clearly Marked Historical Material" component. This component hardcodes a persistent visual watermark across the WebXR scene, explicitly stating that the scenario is a historical analysis and does not represent a current operational picture.

Publishing States

Scenarios exist within a strictly governed lifecycle managed through role-based access control (RBAC).

When an "Approved Public" scenario undergoes revision, it triggers a new cryptographic hash and version ID. Existing challenge links and embeds maintain the old version to preserve educational continuity, tournament integrity, and historical context, unless the older version is forcefully deprecated by moderators due to a late-discovered safety violation.

Creator Trust Levels

The platform employs a graduated trust system that balances the need for rapid community growth with the absolute necessity of stringent safety oversight. A creator's trust level dictates the depth of automated review required, publication speed, and access to advanced components.

1. New Creator: The default entry tier. Scenarios are subjected to maximum automated scrutiny. Every publication requires manual human review by a Staff Editor before transitioning to the "Approved Public" state.

2. Verified Educator: Requires institutional email verification (e.g., .edu, .k12) or syllabus review. Educators are granted instant publication rights to the "Classroom-Only" state, facilitating rapid curriculum development. Public gallery submissions remain subject to light manual review.

3. Verified Researcher: Requires a demonstrable publication history or academic affiliation. Permits the use of advanced theoretical AI architectures in scenarios, pending automated safety checks.

4. Trusted Publisher: Achieved after successfully publishing 10 "Approved Public" scenarios with zero safety violations and maintaining high community ratings. Grants bypass of the manual human review queue for publication, relying entirely on the platform's robust automated deterministic safety checks.

5. Staff-Curated Partner: Reserved for organizations (e.g., think tanks, cybersecurity firms) operating under direct partnership agreements. Granted custom branding capabilities and priority featuring in the gallery.

6. Restricted Creator: A temporary punitive state applied after a minor formatting or source quality violation. Imposes a 14-day publication cool-down and mandates strict human review for all subsequent submissions. Appeals are processed automatically after the expiry period.

7. Suspended Creator: Applied immediately following a severe safety violation (e.g., attempting to publish operational targeting data or functional malware). Revokes all authoring and publishing privileges. Appeals require manual review by the Trust & Safety lead and are rarely granted.

No creator, regardless of trust level or partnership status, is allowed to bypass the non-negotiable automated safety validations regarding synthetic data enforcement and schema determinism.

Community Gallery

The Community Gallery serves as the primary discovery engine for published scenarios. The architecture strictly rejects engagement-bait algorithms; it does not rank content based on outrage, political alignment, high failure rates, or raw click volume. Instead, ranking is derived from a composite "Educational Quality Score," encompassing:

• Completion Rate: Scenarios that are statistically impossible to complete due to poor design are downranked.
• Accessibility Pass Rate: Scenarios utilizing WCAG 2.2 compliant labeling and spatial audio via Web Audio API17 receive a significant algorithmic boost.
• Debrief Quality: Measured by the depth, length, and clarity of the post-scenario explanation.
• Source Transparency: The quantity and validity of cited external references.
• User Satisfaction: Post-completion qualitative ratings from players.

The UI utilizes WebXR-optimized cards. Hovering over a card renders a lightweight 3D preview of the scenario's topological graph without loading the full simulation. Users can filter by category (AI Security, Cyber Defense, Human Control, Evidence Analysis), difficulty, estimated completion time, and Trust Label. A robust spoiler-handling mechanism algorithmically obscures discussions regarding optimal decision paths in the comments and review sections.

Remix System

To encourage iterative learning and ecosystem enrichment, the platform features a secure Remix System, allowing users to clone and modify public scenarios. Preservation Rules: The remix function automatically preserves the parent scenario's source list, safety constraints, original creator attribution, and licensing terms. The system maintains a transparent, user-viewable Directed Acyclic Graph (DAG) of the scenario's lineage, allowing players to trace the evolution of a concept. Material vs. Cosmetic Changes: A remix does not automatically inherit the public approval status of its parent if material changes are made.

• Cosmetic Remix: Changing node colors, updating text localization (Translation), adapting the difficulty via timer adjustments, or adding accessibility features. These changes inherit the parent's approval status for immediate sharing.
• Material Factual/Safety Change: Altering the state machine logic, adding new decision branches, changing the learning objective, uploading new evidence files, or expanding the content scope. These changes strip the scenario of its "Approved Public" status, forcing the remix back into the "Private Draft" state to undergo the full automated and manual moderation pipeline.

Weekly and Seasonal Programs

To stimulate organic community growth and direct creator energy toward constructive, highly educational themes, the platform curates 12 structured programs:

1. Weekly Break-the-Chain: A prompt focusing on disrupting a specific phase of the cyber kill chain or the F2T2EA process1.

2. Educator Challenge: Developing scenarios specifically mapped to undergraduate cybersecurity or political science syllabi.

3. AI-Security Month: Utilizing the MITRE ATLAS framework to design scenarios around emerging threats like prompt injection (AML.T0051) and model evasion5.

4. Evidence-Verification Week: Scenarios focusing entirely on resolving conflicting sensor data, identifying deepfakes, and managing analytical uncertainty.

5. Human-Control Design Challenge: Crafting scenarios that require precise human-machine teaming and authorization, reflecting the strictures of DoD Directive 3000.099.

6. Accessibility Remix Week: A bounty program rewarding creators who take existing popular scenarios and retrofit them with perfect WCAG 2.2 compliance17.

7. Best Debrief Challenge: Rewarding the most articulate, theoretically sound, and well-cited post-scenario explanations.

8. Beginner Creator Workshop: A guided, facilitated sprint designed to help New Creators achieve their first successful publication.

9. Historical Doctrine Explainer: Adapting declassified, historical military or cyber events into the synthetic framework using the Historical Material component.

10. Defensive Architecture Challenge: Focusing purely on the optimal application and configuration of NIST SP 800-53 controls14.

11. Team Scenario Jam: A 48-hour collaborative building event fostering interdisciplinary cooperation between technical and policy experts.

12. Annual Community Showcase: Featuring the highest-rated educational simulations of the year, culminating in a virtual conference.

Rewards emphasize credibility and educational value, consisting of unique profile badges, 3D avatar cosmetics, and featured gallery placement. The judging criteria explicitly forbid rewarding scenarios based on destructive effectiveness, operational realism, political alignment, or simulated casualty outcomes.

Badges and Reputation

Badges serve as cryptographic, visual proof of a creator's pedagogical and technical proficiency, displayed prominently on creator profiles and scenario cards.

1. Clear Learning Objective: Granted automatically if the scenario maintains a \>90% positive player feedback rating regarding objective clarity.

2. Strong Sources: Granted by Staff Editors during manual review for exceptional use of primary source documentation and rigorous STIX 2.1 mapping4.

3. Accessible Experience: Granted automatically if the scenario passes all automated WebXR and screen-reader accessibility tests with zero warnings or errors17.

4. Excellent Debrief: Granted based on community upvotes specifically targeting the post-scenario explanation phase.

5. Creative Visualization: Granted by Staff Curators for highly innovative use of glTF 3D assets and spatial organization that enhances comprehension.

6. Defensive Design: Granted automatically when a scenario correctly implements and contextualizes at least three distinct NIST 800-53 control families15.

7. Human-Control Clarity: Granted by Staff Editors for scenarios that accurately capture the complexities of human-in-the-loop authorization13.

8. Evidence Transparency: Granted for utilizing the "Conflicting Report" or "Confidence Estimate" components effectively to teach analytical humility.

9. Classroom Tested: Granted automatically when a Verified Educator assigns the scenario to a cohort of \>20 students and achieves a high completion rate.

10. Community Mentor: Granted to creators who consistently provide constructive, highly-rated feedback on scenarios in the "Review Requested" queue.

Badges can be instantly revoked by Trust & Safety Staff if a creator's subsequent behavior violates community guidelines or if a scenario is found to contain disguised malicious content post-publication.

Moderation System

Governance relies on a layered, defense-in-depth moderation model: Automated Field Validation → Pattern and Entity Detection → Safety Classification → Source Checks → Community Reporting → Specialist Review → Urgent Takedown → Creator Notification → Appeal → Correction/Redaction → Audit Trail.

The audit trail for all moderation actions is cryptographically signed and stored in a tamper-evident database, ensuring total transparency and accountability for the moderation team.

Copyright and Licensing Rules

The platform operates on a default Creative Commons Attribution-NonCommercial-ShareAlike (CC BY-NC-SA 4.0) license for all published scenarios, ensuring educational accessibility while protecting creator attribution.

• Creator Ownership: Authors retain full copyright over their original narrative and structural logic. By publishing, they grant KillChains a perpetual, non-exclusive platform display license to host, render, and translate the content.
• Remix Licensing: All remixes automatically inherit the CC BY-NC-SA license. The platform strictly enforces attribution metadata within the JSON schema.
• Source Quotations & Screenshots: Subject to fair use guidelines, strongly encouraged for educational debriefs, provided proper citations are included.
• 3D Assets and Audio: Authors must certify that all uploaded glTF models and audio files are original, public domain, or licensed appropriately. The system utilizes perceptual hashing algorithms to block the silent ingestion of known proprietary meshes.
• AI-Generated Assets: Any AI-generated text or images used as synthetic evidence must be explicitly tagged using the platform's metadata toggle, ensuring complete transparency regarding synthetic media origins.
• Government Works: Permitted and encouraged for policy documents, marked automatically as public domain where applicable.
• Takedown Requests: Processed via standard DMCA protocols.
• Export: Creators can export their approved scenarios as self-contained JSON/GLB packages for offline educational use, preserving the open nature of the standard26.

Classroom Mode

To facilitate rapid institutional adoption and support formal education, the Creator Studio features a dedicated Classroom Mode engineered for strict compliance with FERPA and COPPA guidelines35. Educators can create private, ephemeral cohorts. Learners access the platform using anonymous aliases generated by the educator, preventing the collection or exposure of student Personally Identifiable Information (PII). Educators possess granular control over assignment parameters, configuring due dates, attempt limits, and the visibility of hints. A critical pedagogical feature allows the delayed release of the debrief explanation until the due date expires, preventing students from sharing the optimal path. Within Classroom Mode, public ranking and social sharing functionalities are disabled by default. Educators access a dashboard displaying aggregate results, branching path analytics, and approved learning metrics, which can be exported via CSV. Cohort data is automatically purged upon reaching the educator-defined deletion date to minimize data liability, and accessibility accommodations (e.g., extended timers, forced high-contrast modes) can be applied per alias.

Viral Loop Analysis

The Creator Studio drives organic, non-exploitative community growth through a structured, 10-step viral loop focused on educational enrichment:

1. Create: A user authors a scenario to solidify their own understanding of a complex topic (e.g., MITRE ATLAS AI threats36). Value: Active learning & synthesis.

2. Test: The author plays through their own scenario in WebXR. Value: Immediate visual feedback and spatial understanding.

3. Publish: The scenario passes safety checks and goes live. Conversion Event: Author commits to their public reputation.

4. Share: The author shares the unique embed link on professional networks. Shareable Artifact: A 3D interactive preview card.

5. Play: External professionals click the link and attempt the challenge. Value: Micro-learning experience; discovering knowledge gaps.

6. Remix: A player realizes they can adapt the scenario for their specific industry context. Conversion Event: Player converts to an Author.

7. Improve: The remixed scenario adds depth, new synthetic evidence, or superior WCAG 2.2 accessibility. Value: Ecosystem enrichment.

8. Feature: Staff curators identify the high-quality remix and feature it on the front page. Trust Mechanism: Editorial endorsement and Badge awarding.

9. Collection: Verified Educators group the featured scenarios into academic syllabi. Conversion Event: Institutional adoption.

10. Event: The platform hosts a thematic community event (e.g., AI-Security Month), driving users back to step 1\.

Abuse Risk & Guardrail: The primary risk in this loop is coordinated algorithmic manipulation to feature low-quality or politically motivated content. The guardrail is the Educational Quality Score, which strictly decouples ranking from raw traffic, relying instead on completion metrics, debrief quality, and verified educator adoption.

Measurement

Success and platform health are continuously monitored via telemetry, strictly decoupled from user PII. Key metrics include:

• Acquisition & Activation: Scenario creation started, Draft completed, First play.
• Throughput & Friction: Review submission rate, Approval rate (measuring friction in automated safety checks), Correction rate (number of scenarios returned for edits).
• Engagement: Completion rate (by scenario), Share rate, Remix rate.
• Ecosystem Health: Collection addition rate, Classroom assignment volume.
• Trust & Safety: Report rate (user flags per 1,000 plays), Source-quality pass rate, Accessibility pass rate17.
• Retention & Conversion: Creator retention (authors publishing \>1 scenario), Player return rate, Featured-to-organic conversion rate.

MVP, Second Release, and Advanced Roadmap

Phase 1: Minimum Viable Product (MVP) \- Months 1-4

• Deployment of the core authoring flow with a robust 2D user interface.
• Release of 10 foundational templates across AI Security and Cyber Defense.
• Implementation of the JSON Schema (Draft 2020-12) deterministic branching engine19.
• Deployment of basic automated safety checks (Regex for IP ranges, RFC reserved domains24).
• Availability of "Private Draft" and "Approved Public" publishing states.

Phase 2: Second Release \- Months 5-8

• Integration of full WebXR preview mode and Web Audio API spatial audio18.
• Expansion to the full 17 templates, including Military Governance (F2T2EA).
• Implementation of the Remix engine and DAG version control tracking.
• Launch of Classroom Mode for verified educators.
• Introduction of the Community Gallery and the initial 5 Badges.

Phase 3: Advanced Roadmap \- Months 9-12+

• Introduction of a visual, drag-and-drop 3D topological editor.
• Integration of IEEE 2888 spatial computing standards for advanced virtual sensor and actuator simulation, bridging synthetic physical and cyber environments37.
• Federated publishing capabilities, allowing approved organizations to host private instances of the Creator Studio synced with the main safety definitions.
• AI-assisted accessibility generation (e.g., auto-generating accurate alt-text and spatial cues for synthetic evidence).

Staffing and Review Roles

The governance of the Creator Studio requires a specialized, cross-functional team to maintain the delicate balance between open creation and absolute safety:

• Trust & Safety Engineers (Tier 1): Responsible for maintaining the automated regex filters, JSON schema validation logic, and managing the heuristic detection of operational targeting data and exploit code.
• Content Moderators (Tier 2): Human reviewers responsible for checking the "Review Requested" queue, verifying source quality, ensuring synthetic data compliance, and issuing "Changes Required" notices.
• Subject Matter Curators (Tier 3): Domain experts in cybersecurity, AI safety, and military doctrine. They define the templates, evaluate edge cases, grant specialized badges (e.g., "Human-Control Clarity"), and curate the front page.
• Trust & Safety Lead (Escalation): Handles appeals for suspended accounts, coordinates with legal entities for imminent harm threats or severe doxxing, and oversees the platform's overall risk posture.

Risks and Mitigations

Risk 1: Dual-Use Operational Utility

• Threat: A user attempts to model a highly classified, real-world network architecture to test intrusion hypotheses or identify operational vulnerabilities.
• Mitigation: The declarative nature of the engine strictly prohibits arbitrary code execution, packet crafting, or network requests. The uncompromising enforcement of RFC 2606/6761 reserved domains24 and documentation IP ranges mathematically prevents real-world mapping. Scenarios remain purely synthetic educational constructs.

Risk 2: Distribution of Exploit Code

• Threat: Malicious actors attempt to upload 0-day malware scripts or shellcode disguised as synthetic "Evidence" logs or policy documents.
• Mitigation: All uploads are aggressively sanitized. The UI renders text and images passively. No component possesses an execution context, rendering any uploaded code inert and harmless.

Risk 3: Misinformation and Propaganda

• Threat: The platform is exploited to simulate geopolitical conflicts using heavily biased, unsupported claims to drive a political narrative or simulate unverified accusations.
• Mitigation: The Educational Quality Score severely downranks scenarios lacking verifiable, transparent sources. The Moderation Framework includes strict severity levels for "Unsupported Claims," allowing rapid takedowns of politically motivated propaganda that lacks foundational educational value.

Testable Acceptance Criteria

To validate the implementation of the Creator Studio, the engineering team must satisfy the following deterministic criteria prior to launch:

1. AC-01 (Data Enforcement): Attempting to input a live, non-reserved IP address (e.g., 8.8.8.8) into any node field results in a hard validation error, prompting the user to use a synthetic range.

2. AC-02 (Logic Safety): Attempting to input \<script\>alert(1)\</script\> or any Javascript eval() logic into a branching condition results in an immediate schema rejection by the parser.

3. AC-03 (Privacy): A scenario published to the "Classroom-Only" state cannot be accessed by an unauthenticated user, nor can it be indexed by external search engines.

4. AC-04 (Lineage): A user modifying an "Approved Public" scenario via the Remix function automatically spawns a "Private Draft" with a new ID, leaving the original intact and retaining the parent attribution.

5. AC-05 (Accessibility): Automated accessibility scanners confirm that all 3D nodes within a template possess valid ARIA labels or equivalent WebXR screen-reader tags prior to publication17.

6. AC-06 (Asset Safety): An uploaded glTF asset containing a prohibited KHR\_interactivity script node is intercepted and rejected by the asset pipeline27.

7. AC-07 (State Machine): The deployment of a "Defensive Control" node correctly updates the scenario's JSON state machine, creating a valid, navigable deterministic branch for the player without generating an infinite loop.

Works cited

1. Joint Publication 3-60: Targeting Doctrine | PDF | Command And Control \- Scribd, https://www.scribd.com/document/75962718/Joint-Targeting

2. Time Sensitive/Dynamic Targeting Analysis Techniques and Results 10th ICCRTS Paper \#263 \- ExtendSim, https://extendsim.com/images/downloads/papers/logistics-usaf.pdf

3. IntelEX: A LLM-driven Attack-level Threat Intelligence Extraction Framework \- arXiv, https://arxiv.org/html/2412.10872v1

4. Introduction to STIX, https://oasis-open.github.io/cti-documentation/stix/intro.html

5. MITRE ATLAS: AI security framework with 16 tactics and 84 techniques \- Vectra AI, https://www.vectra.ai/topics/mitre-atlas

6. Agentic AI Threat Evidence: OWASP to MITRE ATLAS \- Stingrai, https://www.stingrai.io/blog/owasp-agentic-threat-classes-mitre-atlas-crosswalk

7. jp 3-60 Joint Targeting \- BITS, https://www.bits.de/NRANEU/others/jp-doctrine/jp3\_60(07).pdf

8. Machines Under Command \- The American Mind, https://americanmind.org/salvo/machines-under-command/

9. DoD Announces Update to DoD Directive 3000.09, 'Autonomy In Weapon Systems', https://www.war.gov/News/Releases/Release/article/3278076/dod-announces-update-to-dod-directive-300009-autonomy-in-weapon-systems/

10. What is MITRE ATLAS? \- CrowdStrike, https://www.crowdstrike.com/en-us/cybersecurity-101/artificial-intelligence/mitre-atlas/

11. Special-use domain name \- Wikipedia, https://en.wikipedia.org/wiki/Special-use\_domain\_name

12. Clarification on RFC 2606 & 6761 regarding the reserved domains \- Server Fault, https://serverfault.com/questions/1022124/clarification-on-rfc-2606-6761-regarding-the-reserved-domains

13. DoD Directive 3000.09, November 21, 2012; Incorporating Change 1, May 8, 2017, https://ogc.osd.mil/Portals/99/autonomy\_in\_weapon\_systems\_dodd\_3000\_09.pdf

14. NIST 800-53 Data Classification: Complete Guide \[2026\] | Isora GRC, https://www.saltycloud.com/blog/nist-800-53-data-classification/

15. NIST 800-53 Controls: Complete Guide \[2026\] \- Isora GRC, https://www.saltycloud.com/blog/nist-800-53-controls-overview/

16. What are the NIST 800-53 Baselines? \- Secureframe, https://secureframe.com/hub/nist-800-53/baselines

17. Accessible 3D Interfaces: Three.js and WebGL | IGC, https://www.intelligentgraphicandcode.com/development/threejs-interfaces/accessibility

18. PannerNode \- Web APIs | MDN, https://developer.mozilla.org/en-US/docs/Web/API/PannerNode

19. json-schema-spec/ietf/json-schema-media-types.md at main \- GitHub, https://github.com/json-schema-org/json-schema-spec/blob/main/ietf/json-schema-media-types.md

20. JSON Schema Serializer and Deserializer for Schema Registry on Confluent Platform, https://docs.confluent.io/platform/current/schema-registry/fundamentals/serdes-develop/serdes-json.html

21. DRAFT Global Digital Citiverse Framework | ITU, https://www.itu.int/metaverse/wp-content/uploads/2025/11/DRAFT-Global-Digital-Citiverse-Framework.pdf

22. Edge IoT Industrial Immersive Technologies and Spatial Computing Continuum, Release 1 \- AIOTI, https://aioti.eu/wp-content/uploads/AIOTI-Paper-Edge-AI-IoT-Immersive-Technologies-Published.pdf

23. .invalid \- Wikipedia, https://en.wikipedia.org/wiki/.invalid

24. RFC 6761 \- Special-Use Domain Names \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc6761

25. KhronosGroup/glTF: glTF – Runtime 3D Asset Delivery \- GitHub, https://github.com/khronosgroup/gltf

26. Remote Visualization and Optimization of Fluid Dynamics Using Mixed Reality \- MDPI, https://www.mdpi.com/2076-3417/15/16/9017

27. glTF/extensions/2.0/Khronos/KHR\_interactivity/Specification.adoc at main · KhronosGroup/glTF · GitHub, https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR\_interactivity/Specification.adoc

28. STIX 2.1 Indicator Patterning and Detection Development | Filigran Blog, https://filigran.io/blog/stix-2-1-indicator-patterning-and-detection-development/

29. AI/Agentic Threat Modeling: Securing Systems That Include Agents | Augment Code, https://www.augmentcode.com/guides/ai-agentic-threat-modeling

30. What Is MITRE ATLAS? Framework Guide for Security Teams \- LayerX, https://layerxsecurity.com/learn/mitre-atlas/

31. MITRE ATT\&CK and ATLAS Agentic Gap Analysis: Techniques Unique to Autonomous Agent Control Planes \- Cloud Security Alliance, https://labs.cloudsecurityalliance.org/agentic/csa-research-note-atlas-agentic-gap-analysis-20260327/

32. Understanding JSON Schema, https://json-schema.org/UnderstandingJSONSchema.pdf

33. Part 4 of 5; NXDOMAINS, SSAC's SAC045, and new gTLDs \- Verisign Blog, https://blog.verisign.com/security/part-4-of-5-nxdomains-ssacs-sac045-and-new-gtlds/

34. RFC 2606 \- Reserved Top Level DNS Names \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc2606

35. Children's Online Privacy Protection Rule ("COPPA") \- Federal Trade Commission, https://www.ftc.gov/legal-library/browse/rules/childrens-online-privacy-protection-rule-coppa

36. SAFE-AI A Framework for Securing AI-Enabled Systems \- MITRE ATLAS™, https://atlas.mitre.org/pdf-files/SAFEAI\_Full\_Report.pdf

37. Advancing Modern Power Grid Planning Through Digital Twins: Standards Analysis and Implementation \- MDPI, https://www.mdpi.com/1996-1073/19/2/556

38. \[2203.02662\] A Survey on Metaverse: Fundamentals, Security, and Privacy \- ar5iv \- arXiv, https://ar5iv.labs.arxiv.org/html/2203.02662

39. IEEE 2888.3-2024 \- IEEE SA, https://standards.ieee.org/ieee/2888.3/10470/