Credits answer who contributed. A license or written permission answers what you may do with someone else's work. Those are different records, and a clean publishing workflow keeps both attached to every borrowed dependency before a project is released.

Build the source record before publication

Create one entry for each third-party texture, model, sound, script, library, map component, reference asset, or collaborator contribution. Record:

• the project or asset name;
• the creator or rights holder exactly as the source identifies them;
• the creator-controlled source URL;
• the exact license name and link, or the written-permission record;
• the version or dated source state you used;
• any changes you made;
• where the material appears in your release;
• any notice, attribution, share-alike, or distribution condition that still needs review.

A homepage link or a creator name by itself is not a complete license record. Preserve the exact source that governs the version you used, and recheck it before a new release.

Separate three permission states

Use a fail-closed status for each dependency:

1. License identified: the governing text is linked and its conditions have been reviewed for the planned use.
2. Direct permission recorded: the rights holder supplied permission that covers the planned use, and the record states its scope.
3. Permission unresolved: the source is missing, the license is unclear, or the planned use is outside the documented terms.

The third state is a stop signal. Do not replace it with “credit to the owner,” a search-result link, or an assumption that free access means free reuse. Remove or replace the dependency until the rights state is clear.

Write credits that can be audited

Group credits by function so a player or reviewer can trace them: building, code, textures, models, audio, testing, translation, and other contributions. Use the contributor's requested public name when known. Link to the creator-controlled source, not a repost or download mirror.

If a dependency was modified, say what changed without implying that you own the original. If different files use different terms, keep separate entries. A single project-wide license label should not hide asset-specific conditions.

Keep release notes and the rights record together

When a dependency changes, update its source, version, modification note, and permission state in the same revision. If a creator removes a page or changes a license, do not silently carry the old claim forward. Preserve the prior audit record and make a new release decision from the evidence that still applies.

The current Minecraft EULA distinguishes original creator work from Minecraft-owned content and directs creators to current Usage Guidelines. It provides a general official boundary only; it is not individualized legal advice and does not grant permission for third-party material.

Final disclosure gate

Do not publish until every dependency has an identified source, a resolved permission state, accurate credit, and a record of modifications. This page owns the disclosure workflow. Portfolio selection, project storytelling, and presentation order belong to the separate portfolio guide.

A strong Minecraft portfolio helps a reviewer understand what you made, why you made it, and which decisions were yours. It is more than a gallery of finished screenshots. The useful part is the context around each project: the goal, your role, the constraints, the result, and what you would improve next.

Choose projects that prove different skills

Start with a small, deliberate set of work instead of every build or experiment you have saved. Pick projects that show different kinds of judgment. A world build might demonstrate composition and navigation. A resource or tool might demonstrate a technical workflow. A collaborative project might demonstrate planning and communication.

Do not claim work simply because you appeared in it or helped publish it. State your contribution in plain language. If you designed the layout but another creator handled commands, modeling, textures, or testing, say so. Reviewers should be able to separate the team result from your individual role.

Give every project a compact context card

For each selected project, answer the same practical questions:

• What problem, player experience, or creative goal did the project address?
• Was it made for Java Edition, Bedrock Edition, or a clearly named toolchain?
• What part did you personally plan, build, write, test, or coordinate?
• Which constraints shaped the result, such as device limits, a deadline, accessibility, or multiplayer use?
• What evidence can a reviewer inspect at the creator-controlled source?
• Is the project current, archived, experimental, or no longer maintained?

These are editorial prompts, not proof of compatibility or quality. Keep version, performance, download, and gameplay claims tied to their own current source or test record.

Show decisions, not only outcomes

Use material you own or have permission to publish to explain one or two decisions inside each project. You might compare an early layout with the final route, explain why a palette changed, or describe how player feedback altered the scope. The point is to reveal your process without turning the page into a step-by-step installation guide or a technical claim you cannot support.

Link to the creator-controlled project page when a reviewer needs the current release or full project record. Do not rehost files, copy another creator's gallery, or treat a public link as permission to reuse its media.

Keep the rights boundary visible

The current Minecraft EULA distinguishes original creator work from Minecraft-owned content and points creators to current Usage Guidelines. That is a general official rights boundary, not individualized legal advice and not permission for any third-party asset.

This portfolio page should identify your work and provide context. Detailed source attribution, permission, and license-record keeping belong to the separate credits and licensing workflow, not inside every project narrative.

Final portfolio review

Before sharing the portfolio, check that every project has a clear purpose, an honest role statement, an edition or toolchain boundary, a current source route, and only media you may publish. Remove duplicated projects that prove the same skill. Keep the strongest example and use the saved space to explain the decisions behind it.