Moodify

An open protocol and reference implementation for evolving audio intelligence.

Generated is not finished. 生成，不等于完成。

Fork the code. Join the process. 代码可以复制，过程需要参与。

---

Five layers, one product

Moodify = Core + Protocol + Studio + App + Network

Not five products — five layers of one product, each with a single responsibility.

Layer	Responsibility	Lives in
Core	Audio analysis, processing, verification, playback capability	moodify-core-package/
Protocol	Stable contracts between Core, Studio, App, agents and future integrations	protocol/ + docs/protocol/
Studio	Creator-side desktop workspace: create, process, review, finish, publish	moodify-desktop/
App	Personal music node: receive, store, play — sharing comes later	Listener-side clients
Network	Connect personal music nodes and creators	not implemented — see below

One Core, many interfaces. An interface must never keep its own copy of a sound algorithm, and no capability has two owners.

The first product loop

Studio → Publish to My Library → Phone → Play

I finish a song on my computer, press Publish to My Library, and the song appears on my phone so I can immediately listen to it.

That single loop, working reliably, is already a valid product. Social features grow from it later — not the other way around. None of it is built yet; see the status table below.

Two different things called "Network"

This is a real term collision, so it is stated plainly:

• Moodify Network (product layer) — connecting personal music nodes. Not implemented. In V1 it means exactly two nodes: your desktop and your own phone.
• Moodify Network (collaboration) — the open process around the Protocol, Core and Evidence: fork, experiment, produce evidence, open a MIP, and the result can re-enter the canonical project. This one is real and documented in GOVERNANCE.md.

Product strategy

stability > novelty · completion > ambition
working loop > architecture purity · maintainability > technical fashion

Mature, public, common technology first: existing > standard library > mature OSS > commodity service > custom > experimental. The burden of proof is on custom and experimental. See docs/canon/TECHNOLOGY_PRINCIPLES.md and docs/canon/PRODUCT_DEFINITION_V3.md.

---

Windows downloads

Official Windows builds are published through GitHub Releases.

Moodify is open-source software licensed under GPL-3.0.

Official Windows binaries are:

• built with GitHub Actions
• code-signed through SignPath Foundation
• accompanied by SHA256 checksums (SHA256SUMS.txt)
• accompanied by GitHub artifact attestations

# integrity — the checksum must match the file you downloaded
sha256sum -c SHA256SUMS.txt

# provenance — this binary was built by this repository's CI, from a specific commit
gh attestation verify Moodify_Studio_*_Setup_x64.exe --repo huliye24/moodify-ai

What those guarantees do and do not cover

The Windows Authenticode publisher is SignPath Foundation, not Moodify. That is the current, deliberate trade-off for a zero-cost release chain; a future release may move to a project-owned certificate. See docs/releases/WINDOWS_CODE_SIGNING.md.

Code signing and artifact attestation answer different questions. Signing says who published the bytes; attestation says which commit and workflow produced them. Neither is a claim that the software is free of defects, and neither should be read as "safe", "fully trusted" or "Microsoft certified" — those claims cannot be proven and are not made.

A valid signature also does not by itself remove the Windows SmartScreen prompt: publisher reputation accumulates over downloads. Before signing is enabled, RELEASE_MANIFEST.json reports code_signed: false, measured from the artifact rather than assumed.

Full detail: docs/releases/ — trust audit, signing, provenance, and the MSIX/Microsoft Store compatibility spike.

---

Quick start

Two interfaces share the Core. CLI is the Creator side — the action is PROCESS. App is the Listener side — the action is PLAY.

python -m pip install -e moodify-core-package

Save this as job.json, with the audio beside it at audio/source.wav. Relative paths in a job resolve against the job file's own directory.

{
  "protocol": "moodify.sound/0.1",
  "source": "audio/source.wav",
  "preset": "clean_master",
  "output_dir": "outputs"
}

moodify protocol validate job.json
moodify protocol process  job.json

The CLI writes JSON to stdout (errors to stderr as JSON, exit code 2). The result carries the output WAV path, input and output SHA-256, the parameters actually applied, and diagnostics, with status processed_review_required.

processed_review_required means the execution path completed. It does not mean the audio is finished. Human listening and release authority are not delegated to the protocol. That is the whole point of Generated is not finished.

Presets: clean_master, warm_vocal, wide_space. Human workbench: moodify-desktop/.

What is verified, and what is not

This project separates what has been demonstrated from what is aspirational, and says which is which.

Demonstrated. The protocol validate/process path runs end to end through the Core and returns hash-verified artifacts. The measurement, diagnosis, and controlled-intervention capabilities are implemented and tested in Core. Private deployment works from pip.

Not demonstrated. Automated perceptual validation. A complete Import → Analyze → Diagnose → Plan → Process → Verify → Export finishing session. An editable Mix Graph. Cloud production carrying real listening traffic.

Not built at all — the entire first product loop above. There is no publish action, no track package, no LAN transfer or pairing, no Android receive, and no local library. A repository-wide search finds no publish to my library, lan sync, pairing token, or local transfer implementation. The same applies to identity, accounts, device registration, and every Network feature.

Unresolved. Cloud runtime state is unverified — the database check was blocked and the record says so rather than guessing. See docs/REPOSITORY_STATUS.md and docs/evidence/README.md.

Never promote a capability to canonical because a document claims it. Evidence is authority tier 4 (docs/canon/AUTHORITY_ORDER.md).

Repository layout

moodify-ai/
├── moodify-core-package/   # Core: the audio intelligence (679 files)
├── protocol/               # Protocol layer: specs, schemas, conformance, MIPs
├── moodify-desktop/        # Studio — the Creator-side workbench
├── apps/                   # Listener-side clients (Android, ear-workbench)
├── docs/
│   ├── canon/              # Authority: identity, boundaries, authority order
│   ├── protocol/           # Sound Protocol specifications
│   ├── evidence/           # Verified runtime evidence (authority tier 4)
│   ├── governance/         # Network process + engineering constraints
│   └── restructure/        # The 2026-10-03 restructure record
├── ops/                    # Deployment, node operation, web origin
├── security/               # Data policy, privacy, threat model
├── schemas/canonical/      # Generated Core contracts
└── tests/                  # Root-level integration tests

Supporting: moodify-music-package/ (music domain API), moodify_runtime/ (commerce), examples/, benchmark/, research/, scripts/, brand/.

Governance in one paragraph

Stewards hold mission, Canon, brand, signing, and security response. Maintainers review and merge. Working Groups form around problems and dissolve. Anyone may contribute — and contribution is not counted in commits: twenty documented A/B judgments from a mastering engineer may be worth more than a large patch. Protocol, schema, contract, governance, and compatibility changes require a MIP, and a proposal cannot be accepted without evidence.

AI agents write code, run benchmarks, and implement MIPs. They do not decide what sounds better, where the project goes commercially, or whether human listening judgment is replaced. Agents have execution rights, not product sovereignty.

No token. No DAO. No airdrop. No treasury governance. Contribution, review, evidence, release, and governance come first.

Contributing

Read AGENTS.md (repository authority), GOVERNANCE.md, and CONTRIBUTING.md. Before changing behavior, data authority, or product language, read docs/canon/.

cd moodify-core-package
python -m ruff check src tests ../tests
python -m pytest -q tests ../tests

Want to propose a change to the protocol? Start with protocol/mips/MIP-0000-template.md.

License

GNU GPL v3.0 only. See LICENSE. Copyright 荣景文川 2024–2026.

---

Moodify — every voice deserves to be heard. 每一种声音，都值得被世界听见。