December 2025 archive: building a model and dependency register
A workflow can combine application code, model weights, adapters, extensions and input material governed by different terms. A dependency register records those components separately so a download link or a permissive software licence is not mistaken for permission covering the entire project.
Inventory the actual components
List each model, adapter and extension used by the saved graph. Include exact variant names, source locations and revisions where available. Record input material separately, including reference images or voices, because permissions for a model do not establish permission to process someone else's material.
Avoid one generic licence field for the entire environment. A repository can contain code under terms that differ from the weights it helps download. Likewise, related model variants may have different conditions. Open the relevant primary model card rather than copying a statement from another family member.
Attach evidence to each entry
Save the primary source URL and the date on which it was checked. Note the component version the source describes. If a download is mirrored elsewhere, keep the upstream identity in the register and verify that the local file matches the intended component where a publisher checksum is available.
Distinguish an explicit statement in a licence from your interpretation of its effect. Record unresolved questions instead of converting a missing restriction into assumed permission. A public model listing and a working download demonstrate availability, not approval for every commercial, redistribution or sensitive-data scenario.
Review changes at the project boundary
When replacing a component, review its entry before adopting it in production. Check compatibility and permissions independently. A faster or smaller variant can change output behaviour and may also have different terms; passing an image-quality check does not settle the latter question.
For hosted execution, add the operator and service terms as separate entries. Record where project inputs are sent and whether additional storage or processing is involved. Do not assume that running an open model through a third party inherits the same privacy boundary as local execution.
Use the register as a handoff, not a verdict
Give the completed inventory to the person responsible for the relevant approval when the project requires it. Include intended use, distribution and any client constraints so review is based on a concrete scenario. Keep approvals and outstanding questions attached to the exact component versions reviewed.
This archive does not provide legal clearance or claim that a model family has one universal licence. Its practical output is a traceable dependency register that supports technical maintenance and qualified review. Revisit entries when components, providers or project purposes change, retaining previous records rather than silently overwriting the basis for an earlier decision.
Sources and further reading
December 2025: dated evidence supplement
Revised 2026-10-01; selected announcement cutoff 2026-09-30. Keep the licence and dependency register; append the dated organisational announcement with its future milestone clearly labelled.
Comfy announced a planned move of its main repository to Comfy Org by 6 January, citing collaboration, access control and development tooling. The December announcement is not itself evidence of the final migration date. Comfy: planned repository move (2025-12-29; company announcement).
Editorial interpretation, not a measured result. Governance and repository identity are part of provenance. Update a dependency register from verified upstream redirects and revisions; do not assume a new organisation name proves a security audit or a different software licence.
No additional financing announcement is established for this month by the reviewed sources. This is not proof that no financing occurred. See the dated funding register; past totals and valuations are not new monthly raises.