Skip to content
XDHD / KnowledgeWorking edition · v0.1

The XDHD field guide.

Creative production, carried forward. Explore the model, the tools and how their parts connect.

48 linked terms · 5 example paths · Draft models + developing components

Start with a small production.

These paths connect the concepts to concrete work. Each step labels what is available, what uses demonstration data and where a handoff is still proposed. They are examples of the direction, rather than promises of a fully integrated pipeline.

01 Turn a note into a title-card project

A map of available local steps and intended handoffs; the complete path is not integrated.

  1. Capture the idea

    Keep the original thought available before organizing it.

    Available: Manual paste/text-file intake and hooks for already-produced Scan files preserve originals and a reviewable text proposal.

    Boundary: TXTX/FSNotes evolution is a broader direction; capture does not automatically make a project or task.

    Available locally
  2. Inspect the clean-text proposal

    Review wording, structure and unresolved placement.

    Available: A deterministic SPAR host can propose normalized Markdown with the received original and a diff; selected-item integration is tested with fixtures.

    Boundary: This is deterministic text handling, not general handwriting understanding or automatic graph reasoning.

    Local capability + fixture integration
  3. Review a pinned candidate

    Separate “ready to inspect” from an accepted production change.

    Available: MEAL/DING local profiles keep a candidate revision, comments and review intent together.

    Boundary: The intake item is not automatically dispatched into MEAL or applied to a real production.

    Local prototype; handoff proposed
  4. Choose the project and component

    Identify where the title card belongs without inventing a destination.

    Available: The model distinguishes project context, production and identity-bearing components.

    Boundary: A complete intake-to-project writer is not connected; a readable address alone does not resolve a real target.

    Proposed handoff
  5. Work on an authored AE0N example

    Explore the title, controls and project view in an isolated working document.

    Available: AE0N fixture editing, references, saved views and some native interactions have been exercised.

    Boundary: Native acceptance is partial; further interaction/recovery acceptance is still needed. It is not yet a reliable production editor.

    Prototype with partial native acceptance
  6. Name the HERO and plan .LIVE

    Keep a primary preview separate from a delivered or operating endpoint.

    Available: Local fixture previews and explicit collection plans can be inspected.

    Boundary: A preview is not a finished render; this walkthrough does not publish a .LIVE endpoint. Renderer conformance and publishing remain separate work.

    Fixture preview; live delivery proposed
02 Build a local graphics-package tree from BLNK lite

Verified data and filesystem rehearsal using demonstrations and labelled placeholders.

  1. Start with a labelled demo

    Choose a bounded example instead of treating every scaffold as finished work.

    Available: BLNK contains curated workflow scenarios, including a graphics package, alongside unfinished scaffolds.

    Boundary: Example documents and scaffolds are not completed products.

    Available fixture
  2. Inspect the lite snapshot

    Keep identities, relationships and source lineage in a compact representation.

    Available: The materializer reads a data-only test snapshot derived from the authored BLNK documents and can resolve known names or IDs.

    Boundary: This bounded lite profile is not a universal XDHD format or a complete media package.

    Verified local profile
  3. Review the proposed tree

    See titles, records, workflow and dependencies before generating files.

    Available: A plan and readable preview show the proposed local tree and customizations.

    Boundary: Human labels and paths are projections; they do not replace stable object identity.

    Verified local planning
  4. Materialize into a fresh workspace

    Produce useful files while retaining the source.

    Available: The pipeline creates project documents, object records, guides, manifests and visibly labelled SVG placeholders, then records output hashes.

    Boundary: No media renderer runs; placeholders are not faithful artwork, video or finished HERO assets.

    Verified local derivation
  5. Compare and open through a compatible loader

    Check provenance and inspect generated project data without pretending it is a completed render.

    Available: Rerun and comparison behavior preserve source lineage; the generated project graph can be inspected by a compatible bounded loader.

    Boundary: A loader check is not native visual acceptance. Shared-owner installation and general heavy-resource packaging remain pending.

    Verified data compatibility; native acceptance limited
03 Plan a weekly programme and view the studio runtime

Local planning is implemented; automatic schedule-to-playout delivery is not connected.

  1. State the dates and time meaning

    Distinguish a deadline, planned day and scheduled programme interval.

    Available: YEAR projects date-only, all-day and timed records; TimeLine can present those records in shared views.

    Boundary: These views do not create a connected calendar account or change the source records.

    Verified local projection
  2. Define and expand the programme

    Turn an explicit weekly recipe into planned occurrences.

    Available: 365.25 supports bounded once, daily and weekly recipes and expands them into planned occurrences.

    Boundary: Fixture planning is separate from actual broadcast history.

    Available local planning + fixture data
  3. Inspect conflicts and missing assets

    Find overlaps and declarations that need review.

    Available: Local UI, CLI and validation API report schedule conflicts, missing media and unfilled time.

    Boundary: Asset lengths and rights are declarations; this step does not independently decode or clear the media.

    Verified local validation
  4. Review an immutable plan export

    Pin the version being reviewed.

    Available: The local release rehearsal records plan and asset hashes and produces a reviewable export.

    Boundary: Dispatch is not attempted; an export does not update a station queue.

    Local rehearsal
  5. Listen in 24HR

    Use the current player while keeping actual playback separate from the plan.

    Available: Intentional Play can start an external radio stream with m0sh visuals.

    Boundary: The plan above does not drive that stream, and playback here is not a complete actual-playout ledger.

    Available runtime; planning handoff proposed
  6. Use the ambient Studio board

    Put clocks, date notes, drawing and listening on a studio screen.

    Available: The browser-based board prototype supplies those views with local persistence and exports.

    Boundary: Its notes are not the programme master; connected calendars, shared presence and multiuser state remain future work.

    Browser-local capability; shared integration proposed
04 Prepare a four-track album demo

A local album fixture and collection rehearsal, not an uploaded release or embedded production-audio engine.

  1. Choose the SRZA house profile

    Start with music-focused vocabulary and useful defaults.

    Available: Trusted profile records supply artist, album, track, artwork, video and collaboration workflow descriptions.

    Boundary: Choosing a profile does not import the artist library or port every SRZA engine into AE0N.

    Available prototype profile
  2. Create a local album fixture

    Give the demo an artist name, title and four tracks.

    Available: The local scaffold supports an explicit bounded track count and offline-WIP or retained-work-feed lifetime.

    Boundary: The generated graph is demonstration data, not a new release in a live catalog.

    Verified local fixture creation
  3. Work through tracks, artwork and video

    Keep the album structure and proposed deliverables visible together.

    Available: The fixture carries track placeholders, artwork/video workflow steps and saved project views.

    Boundary: Audio processing, complete artwork generation and external tools need their own implemented adapters.

    Fixture workflow; broader engines pending
  4. Retain the working document

    Keep unfinished work local until collection is useful.

    Available: Saved storage intent distinguishes retained local WIP, retained work feed and fixture collection.

    Boundary: Retained work feed is not automatic deletion or publication.

    Available local intent model
  5. Review dependencies and collect locally

    Make copy/reference choices and inspect missing resources before a snapshot.

    Available: The fixture engine plans a declared dependency closure and can create an explicit local collection with a receipt.

    Boundary: Referenced assets make a collection non-self-contained. The native loader does not yet automatically relink media from that collection manifest.

    Verified fixture engine; native execution unverified
  6. Prepare a later release decision

    Treat catalog commitment and public release as separate milestones.

    Available: The prototype retains the proposal and source lineage for later review.

    Boundary: No canonical catalog write, release upload or public publishing occurs in this example. Album and collaboration naming mappings remain open.

    Proposed production handoff
05 Use one project through CORE, a HOST and a RACK view

An AE0N demonstration of the architecture; complete cross-platform parity is still a direction.

  1. Keep project meaning in portable contracts

    Separate production records from the interface that displays them.

    Available: Existing modules provide reusable validation, identity-aware records and bounded transformations.

    Boundary: CORE extraction is incremental; the whole system is not already host-independent.

    Implemented modules within draft architecture
  2. Let the HOST supply real capabilities

    Use the platform for file selection, windows, input and rendering only where supported.

    Available: The Mac prototype hosts a bounded document loader, saved views and supported controls.

    Boundary: A capability name is not proof of an implemented adapter, and the Mac demonstration does not establish Linux parity.

    Available Mac prototype; parity proposed
  3. Flip the panel over one state

    Inspect properties while keeping the same panel and production object.

    Available: The native demonstration exercised individual/global front-back sides and shared values.

    Boundary: Some editing and recovery interactions remain experimental.

    Partially accepted native behavior
  4. Inspect a typed reference

    See where a title or accent comes from and how an explicit override differs.

    Available: Same-project fixture references, inheritance, override and reset have local/native evidence.

    Boundary: A visible reference is not a commerce connection, arbitrary effect implementation or completed drag-pickwhip tool.

    Available fixture binding
  5. Save a named layout

    Use an authored production view and a compact companion without changing the project identity.

    Available: Named presets, a saved laptop variant and resizing were exercised; the authored target remained intact.

    Boundary: The compact companion is a read-only review preview. Physical-display detection and every recovery case are not accepted.

    Partially accepted native layout behavior
  6. Carry the distinction to another host

    Reuse supported contracts instead of assuming every panel can run everywhere.

    Available: Loader contracts preserve identities, unknown fields and declared supported behavior across consumers.

    Boundary: AE0N panel RACK is distinct from the physical rack/inventory domain also named RACK.CORE. Neither implies universal host or renderer parity.

    Architectural direction with bounded contracts

The ecosystem

XDHD

Draft model

Model + ecosystem

An open creative-production model for giving material identity, relationships and a path from capture to composed and live outcomes.

Part of
The foundation beneath the apps, workflows and infrastructure.
Related
XDHD.SPEC / XDHD.XDHD · XDHD.Pro · XDHD.OS · Cartridges
Developing
Test the draft contracts through real productions.
Scope
The model is open and developing; this guide does not ratify a technical standard.

XDHD.SPEC / XDHD.XDHD

Draft model

Knowledge + specification

The working specification and knowledge collection, preserving distinctions between concepts, implementation profiles and evidence.

Part of
The shared XDHD reference layer; its technical specifications remain Draft.
Related
XDHD · JANK
Developing
Develop the model through review, examples and implementation evidence.
Scope
A working collection rather than a ratified specification.

XDHD.Pro

In development

Native application

The native Mac home for creative tools, local cartridges and media workflows.

Part of
The native creative-tool application in the XDHD.Tools family.
Related
XDHD.CORE / XDHD.HOST · Cartridges · AE0N / .CORE / .MacApp · XDHD.DEUX
Developing
Connect reusable tools through explicit production contracts.
Scope
The native tool home develops module by module; the shell does not imply complete integration of every tool.

XDHD.Studio

Prototype

Studio environment + offer

The production environment connecting persistent media, compute, lightweight authoring and public services.

Part of
The studio/practice layer of XDHD, connecting storage, compute, authoring and public services.
Related
XDHD.Pro
Developing
Prove a complete small production workflow with clear responsibilities.
Scope
The environment and service offer are developing; distributed production and recovery need separate qualification.

XDHD.OS

Prototype

Shared working environment

The common production shell and host-profile direction: shared data and commands, adapted to each machine.

Part of
An implementation surface over XDHD for native, browser and Linux hosts.
Related
XDHD.CORE / XDHD.HOST · HAUX · DEPT / department views · XDHD.OS Linux
Developing
Reuse portable contracts through capability-aware host adapters.
Scope
Shared data and commands do not establish complete behavior or renderer parity across hosts.

XDHD.CORE / XDHD.HOST

Draft model

Architecture + modules

CORE carries reusable models, commands and transformations; HOST exposes the capabilities a particular platform can actually supply.

Part of
The reusable implementation architecture behind OS and product surfaces.
Related
XDHD.OS · XDHD.Pro · XDHD.Appify.CORE · INBX
Developing
Extract shared modules progressively and verify each adapter.
Scope
Existing modules are reusable within declared contracts; full extraction and host parity remain developing.

HAUX

In development

Interface system

The shared house-interface lineage used by XDHD.OS, SRZA.OS and BLNK.OS flavours.

Part of
The shared interface/design-system lineage; HAUX.CORE extraction is developing.
Related
HAUX.STYL · XDHD.OS · DEPT / department views
Developing
Reuse tested components while retaining production-specific identity.
Scope
The adoption baseline is usable; exact geometry, typography and production component extraction remain developing.

HAUX.STYL

Prototype

House workflow profile

A trusted house UI style plus useful default workflows and launchers.

Part of
A house presentation/workflow profile, separate from creative BRND/S0NA and production-layer effects.
Related
HAUX · SRZA.HAUX.Tools · RACK · FNDR / Desktop / work.feed
Developing
Connect the selected workflows to qualified capability adapters.
Scope
A style/profile selects defaults and workflows; it does not grant permissions or supply missing engines.

DEPT / department views

Prototype

Views + capability lenses

Task-specific views over one production: BRND, STYL, UIUX, GFXR craft/workflow, FAFH file/folder references, LENS camera-and-grip, PR0J/PR0D/PR0C, EDIT, CHNL, 24HR, CREW, S0NA and MRKT.

Part of
Views and capability lenses over the shared XDHD production model.
Related
XDHD.OS · HAUX.STYL · Project / production / product
Developing
Develop role-specific tools without confusing visibility with write permission.
Scope
Department views are a developing catalogue; not every controller or permission adapter is implemented.

Contexts + production

Cartridges

Draft model

Working contexts

Scoped creative contexts sharing graph concepts while retaining explicit identity, permissions and membership.

Part of
Scoped contexts within the common identity and relationship model.
Related
BLNK / DEMO.XDHD
Developing
Make identity, permissions and membership explicit in real workflows.
Scope
Shared concepts do not imply shared access or populated example accounts.

BLNK / DEMO.XDHD

Prototype

Demo context + fixtures

The common demonstration lineage, with examples used to test authoring and production flows.

Part of
The shared example/demo lineage used across XDHD surfaces.
Related
Cartridges · AE0N / .CORE / .MacApp · Materialize / Scaffolder · XDHD.Store / Vendure
Developing
Turn bounded demonstrations into reusable, clearly labelled learning paths.
Scope
Examples, scaffolds and placeholders are labelled; a demo is not a finished product.

JANK

Draft model

Identity + addressing

Stable addressability for production objects, with readable expressions pointing to identity-bearing records.

Part of
The identity and navigation layer across production contexts.
Related
TLJ_ / HERO / .LIVE · Project / production / product
Developing
Reconcile readable expressions with explicit object, context and revision resolution.
Scope
Human expressions, filenames and immutable identity have distinct roles; grammar remains a working contract.

TLJ_ / HERO / .LIVE

Draft model

Roots + endpoints

TLJ means Top Level JANK. HERO names a preferred primary visual/endpoint; .LIVE marks external delivery or operation.

Part of
Draft graph organization and endpoint navigation.
Related
JANK · Project / production / product · Collect → commit → publish
Developing
Reconcile root/endpoint grammar with actual source records.
Scope
Named roots and endpoints remain draft; a preferred preview is separate from a live delivery.

Project / production / product

Draft model

Working vocabulary

PR0J establishes owned project context; PR0D is the actual production; a product is an outcome/offer rather than an automatic folder level.

Part of
The living-production model. PR0C is an ID-based, renamable Production Component attached to PR0D.
Related
JANK · CARD / COMP · DEPT / department views · .PROX / .PR0X delivery
Developing
Reconcile older schema wording and test the hierarchy on real work.
Scope
Project, production, component and product roles retain open hierarchy questions.

CARD / COMP

Draft model

Records + compositions

CARD can be an actionable record or a static one-frame projection; COMP is the time-based or otherwise composed output.

Part of
Draft production/materialization vocabulary with PR0C component context.
Related
Project / production / product · Materialize / Scaffolder · AE0N / .CORE / .MacApp
Developing
State the role each concrete profile uses.
Scope
Record and projection uses of CARD remain profile-dependent.

.hifi / .lofi

Draft model

Linked media representations

Heavy/full media and light graph, proxy or working representations linked to the same production identity.

Part of
The storage/materialization model.
Related
pr0j.base · XDHD.lite
Developing
Verify dependency closure, bindings and reconciliation.
Scope
Linked fidelity levels do not establish complete media, automatic synchronization or access.

pr0j.base

Draft model

Filesystem projection

The local filesystem/materialization organization for working contexts, projects and their representations.

Part of
A storage projection of the model, separate from immutable identity and access.
Related
.hifi / .lofi · FNDR / Desktop / work.feed · XDHD.lite
Developing
Keep source bindings explicit across working and stored representations.
Scope
A tree is a navigational projection, rather than identity, ownership or synchronization itself.

XDHD.lite

Draft model

Light representation

A lightweight representation of identities, relationships, manifests and activity, with references to heavier resources.

Part of
The common data/materialization direction.
Related
.hifi / .lofi · Materialize / Scaffolder
Developing
Test complete, lossless local packages with provenance.
Scope
A lightweight representation does not guarantee complete media or universal format compatibility.

Materialize / Scaffolder

Prototype

Local derivation pipeline

A derivation pipeline that turns a lightweight graph into readable local project files while retaining source identity and lineage.

Part of
The Scaffolder/materialization direction within XDHD.
Related
XDHD.lite · BLNK / DEMO.XDHD · pr0j.base
Developing
Qualify richer dependencies and compatible document consumers.
Scope
Available local derivation uses bounded demonstration graphs and labelled placeholders, without running a media renderer.

FNDR / Desktop / work.feed

Prototype

Local authoring surface

Local file/item presence and retained work.feed support offline WIP before acceptance into a cartridge.

Part of
The local-first authoring and storage lifecycle.
Related
pr0j.base · Collect → commit → publish · HAUX.STYL
Developing
Keep working items addressable before deliberate collection.
Scope
Working material can remain useful outside a committed cartridge until a deliberate collection.

Collect → commit → publish

Prototype

Review boundaries

Collect reviews dependencies and destination; graph commitment and public publication are later, distinct actions.

Part of
The local-to-shared production lifecycle.
Related
FNDR / Desktop / work.feed · Cartridges · TLJ_ / HERO / .LIVE
Developing
Make dependency and destination review explicit at every handoff.
Scope
Local/fixture collection exists; production commitment and publication are separate handoffs.

Creative tools + renderers

AE0N / .CORE / .MacApp

Prototype

Living-project control surface

An expanded project control surface for layouts, RACKs, properties, effects, STYL and TimeLine, with native-renderer ancestry.

Part of
A living-project surface related to the m0sh/native renderer lineage.
Related
RACK · Responsive named presets · Pickwhip / live references · m0sh / .m0sh
Developing
Develop reliable authoring, reusable contracts and supported rendering.
Scope
Local authoring and some native interactions exist; native acceptance and renderer conformance are incomplete.

RACK

Prototype

Front / back workspace

AE0N panels with a front for use and a back for properties, effects, STYL and reference wiring.

Part of
The authored living-project workspace within AE0N.
Related
AE0N / .CORE / .MacApp · HAUX.STYL · Pickwhip / live references
Developing
Keep panel views connected to the same project state.
Scope
Panel front/back behavior is a prototype. It is distinct from the physical-rack/inventory domain.

Responsive named presets

Prototype

Authored layouts

Project-owned target layouts for Retina, larger displays and compact/web companions, with guarded save/revert and resize recovery.

Part of
Project-owned AE0N presentation contracts.
Related
AE0N / .CORE / .MacApp · RACK
Developing
Support useful authored views while retaining project identity.
Scope
Authored logical layouts are supported within the prototype; complete display/recovery acceptance is developing.

Pickwhip / live references

Prototype

Typed bindings

Same-project references and inheritance used to wire controls and fixture-driven live views.

Part of
Typed reference and property contracts in the AE0N prototype.
Related
AE0N / .CORE / .MacApp · RACK · XDHD.Store / Vendure · JANK
Developing
Connect supported sources with clear inheritance and override behavior.
Scope
Same-project fixture references and inheritance do not establish a live commerce or arbitrary-effect connection.

m0sh / .m0sh

In development

Creative + performance engine

The existing web creative/render/performance engine and portable preset lineage.

Part of
The creative/performance engine used by standalone and embedded XDHD surfaces.
Related
AE0N / .CORE / .MacApp · XDHD.OS Linux · m0sh.n0de · 365.25 / M1ND.365.25
Developing
Expand supported creative recipes and measure real output behavior.
Scope
Supported recipes and output behavior depend on the engine build and selected host.

Renderer choice: AE + EffectCraft

Draft model

Platform policy

XDHD supports a choice of renderers. Broader XDHD retains optional After Effects; Linux targets m0sh and portable AE0N contracts, with other engines evaluated when needed.

Part of
The renderer strategy, separate from interface and host portability.
Related
AE0N / .CORE / .MacApp · m0sh / .m0sh · XDHD.OS Linux
Developing
Describe and verify the capabilities of each concrete renderer adapter.
Scope
Capability and platform compatibility must be established for each engine; optional integrations are not automatic.

XDHD.Store / Vendure

Prototype

Commerce direction + fixtures

The commerce direction, a read-only SKU evidence registry and isolated authoring fixtures have related but distinct roles.

Part of
XDHD product/commerce work, separate from project-authoring and delivery identity.
Related
Pickwhip / live references · BLNK / DEMO.XDHD
Developing
Connect catalogue and commerce capabilities through explicit adapters.
Scope
Authoring fixtures and evidence registries are not a functioning checkout.

SRZA.HAUX.Tools

In development

Artist workflow profile

Artist/album/track/artwork/video tools and defaults, including compilation and collaboration context.

Part of
The artist/music workflow family, with source-derived HAUX and AE0N profile work.
Related
HAUX.STYL · AE0N / .CORE / .MacApp
Developing
Reuse implemented engines through explicit, tested adapters.
Scope
A house profile does not embed every original artist/audio engine.

.PROX / .PR0X delivery

In development

Delivery package + proposal

An existing directory-package delivery family with frozen selected versions, hashes and recipient notes.

Part of
The delivery-package end of a production, separate from editable masters.
Related
Project / production / product · XDHD.lite · Collect → commit → publish
Developing
Keep selected-version delivery and dependency declarations clear.
Scope
An implemented delivery family with a Draft technical contract; naming proposals are separate from current file identity.

Planning + programming

DDDD

Draft model

Orchestration model

Routes reasoned work toward tasks, time planning, decisions and bounded delegation.

Part of
The intake, assistance, review and reconciliation direction.
Related
XDHD.DEUX · DAUX · MEAL / DING · SPAR
Developing
Reconcile terminology and source-owned planning/delegation adapters.
Scope
The routing model is developing; terminology and execution adapters remain open.

XDHD.DEUX

Prototype

Task-review desktop

A seven-day task-review desktop with Calendar, 365.25 and TimeLine views over supplied records.

Part of
The task-review surface within XDHD.OS.
Related
DDDD · 365.25 / M1ND.365.25 · XDHD.TimeLine
Developing
Connect reviewed tasks to qualified source-owned adapters.
Scope
Local review is implemented; live providers and production task commands need separate integration.

DAUX

Proposed profile

Temporal-planning direction

The proposed time/calendar-planning destination in the current DDDD model.

Part of
DDDD orchestration; separate from the DEUX task-review surface.
Related
DDDD · YEAR.CORE · XDHD.TimeLine
Developing
Define source-owned time-planning adapters.
Scope
A temporal-planning proposal, rather than a separate established calendar application.

MEAL / DING

Prototype

Ordered review

MEAL means Move Everything Along: an ordered review checkpoint. DING marks an exact candidate revision ready for review.

Part of
The shared ordered-review component used by production surfaces.
Related
DDDD · Collect → commit → publish
Developing
Keep feedback and actions bound to the exact reviewed candidate.
Scope
Readiness and approval intent do not themselves apply, execute or publish a change.

YEAR.CORE

In development

Dates + calendar projection

A shared foundation distinguishing planned days, deadlines, all-day ranges, timed intervals and undated work.

Part of
The reusable date/calendar foundation used by planning and programme views.
Related
XDHD.TimeLine · XDHD.DEUX · 365.25 / M1ND.365.25
Developing
Preserve source meaning through qualified projections.
Scope
A source-preserving projection component, not a calendar database or recurrence scheduler.

XDHD.TimeLine

Prototype

Unified source views

Human-and-agent-readable capture, recall, planning and reference views over original records.

Part of
The shared source-projection direction for notes, recall, calendars and programmes.
Related
YEAR.CORE · 365.25 / M1ND.365.25 · DEPT / department views
Developing
Develop source and permission bindings without creating another truth store.
Scope
Views and filters preserve permissions; provider synchronization is a separate capability.

365.25 / M1ND.365.25

In development

Annual programming

Shared annual calendar/programme assembly; M1ND.365.25 is a configured client, not a forked app.

Part of
The annual-programming layer in the 24HR family.
Related
XDHD.TimeLine · XDHD.24HR
Developing
Connect validated plans to media/provider adapters with separate playout evidence.
Scope
Local planning/validation is implemented; a programme plan is not an actual-playout ledger.

XDHD.24HR

In development

Player + runtime

The radio/listener/runtime lineage, paired with programming tools and m0sh visuals.

Part of
The 24HR player/runtime family.
Related
365.25 / M1ND.365.25 · 24HR.Studio · m0sh / .m0sh
Developing
Keep planned programming and actual playback separately inspectable.
Scope
Playback is separate from schedule assembly and needs an intentional user start.

24HR.Studio

Prototype

Ambient studio board

An ambient studio board with clocks, date notes, pins, whiteboard, countdown, radio and m0sh views.

Part of
A browser-based 24HR profile for a studio screen.
Related
XDHD.24HR · 365.25 / M1ND.365.25
Developing
Develop optional shared state and calendar capabilities.
Scope
Working board state is local to its viewing context; shared collaboration is a separate direction.

Capture + assistance

SPAR

Proposed profile

Assistant direction

Studio Personal Assistant and Runner/Renderer: source-grounded assistance, preparation and bounded execution.

Part of
The XDHD assistant direction, with CORE protocols and host-specific adapters.
Related
INBX · DDDD
Developing
Develop source-grounded preparation and bounded execution.
Scope
Capabilities depend on the host; deterministic normalization and general model reasoning remain distinct.

INBX

In development

Canonical local intake

The intake layer above paste/drop and Scan, preserving originals, provenance, extraction and reviewed normalization proposals.

Part of
The shared intake component above text and scan acquisition.
Related
XDHD.Scan / Doxie / photo · TXTX / XTXT / FSNotes · Collect → commit → publish
Developing
Connect reviewed extraction and explicit destination contracts.
Scope
Manual local intake preserves originals. Acceptance here is separate from cartridge commitment.

TXTX / XTXT / FSNotes

Prototype

Text authoring lineage

Low-friction human-readable notes and authoring for capture, Dispatch and decisions.

Part of
The XDHD text-authoring direction; current implementations retain XTXT aliases.
Related
INBX · XDHD.TimeLine
Developing
Preserve sources and qualify selective dispatch/integration.
Scope
Human-readable authoring is a direction with bounded implementations; general text-to-live automation is developing.

14X6 / 1416 notecards

Prototype

Physical-to-graph workflow

Handwritten 4×6 card → preserved capture → reviewed interpretation → staged graph → traceable reverse label.

Part of
The physical-notecard workshop, using Scan acquisition and INBX review.
Related
XDHD.Scan / Doxie / photo · INBX · JANK
Developing
Qualify real capture, traceable labels and deliberate graph placement.
Scope
Demonstration staging does not establish physical scanning, graph commitment or reverse-print acceptance.

XDHD.Scan / Doxie / photo

Prototype

Acquisition routes

First-class card-photo and scanner-export intake with boundary/orientation review and derivative/OCR provenance.

Part of
Acquisition below canonical INBX.
Related
14X6 / 1416 notecards · INBX
Developing
Preserve originals and derivative provenance through real sample acceptance.
Scope
Photo and scanner-export routes are distinct from direct device-driver support.

XDHD.Appify.CORE

Prototype

Native wrapper foundation

A reusable manifest, policy and native-wrapper foundation for web content presented as focused app windows.

Part of
The host-wrapper component direction within XDHD.CORE.
Related
XDHD.CORE / XDHD.HOST · XDHD.OS
Developing
Qualify platform-specific runtime and session behavior.
Scope
Platform wrappers remain experimental; a wrapper does not establish a connected service.

Hosts + dedicated nodes

XDHD.OS Linux

Prototype

Build family

A stripped-down Linux family reusing real CORE/store/navigation/cartridge contracts and m0sh through host profiles.

Part of
The experimental Linux host/profile family for XDHD.OS.
Related
XDHD.CaptureStation · Renderer choice: AE + EffectCraft
Developing
Qualify supported machine roles and real production workflows.
Scope
Experimental host profiles do not establish physical device support or real-time performance.

XDHD.CaptureStation

Proposed profile

Purpose-built profile

A control-room profile for camera ingest, routing, recording, confidence views and separate m0sh program output.

Part of
The OS-agnostic m0sh.n0de direction, with Linux and native macOS host paths under investigation.
Related
m0sh.n0de · XDHD.OS Linux · m0sh / .m0sh
Developing
Qualify exact device, capture, output and storage capabilities before combining them.
Scope
Exact original-device driver support and combined capture/output performance remain unqualified on either host path.

m0sh.n0de

Proposed profile

Dedicated-machine concept

A focused machine that runs m0sh visuals and, where qualified, contributes capture/control to a production.

Part of
The dedicated production-node direction, with CaptureStation as a proposed tier.
Related
XDHD.CaptureStation · m0sh / .m0sh
Developing
Define useful, measured output and capture capabilities for each node.
Scope
A machine role must be qualified separately for capture, output, storage and combined load.

A working model, made inspectable.

XDHD is an open creative-production model. XDHD.Pro, XDHD.OS and the other components realize parts of that model through particular interfaces and hosts. An open specification and a commercial implementation have different roles.

This edition explains purpose and relationships. “Draft model” marks developing semantics; “Prototype” marks bounded experimental behavior; “In development” marks implemented work with a developing scope; “Proposed profile” marks a machine or workflow direction requiring qualification. No label implies universal compatibility or production acceptance.

Examples preserve the distinction between a note, a review proposal, an accepted record, a composed artifact and a live endpoint. A saved preview or fixture result is not automatically a published production.

Definitions and relationships come from one editable entry graph. This public edition includes reviewed concepts and examples; operational history and source receipts remain a separate reference layer. Reviewed 2 November 2026.

Download the public entry graph