Chapter 4: Research Packets

Created by Sarah Choi (prompt writer using ChatGPT)

Research Packets (Taxonomy, Spec Notes, Consultant Credits)

A research packet is the “why and how” behind your mecha designs, organized so the whole team can move faster without drifting. It is not a moodboard, and it is not a dumping ground of links. A good packet is a curated, readable document that turns research into actionable design constraints, shared terminology, and production-ready decisions. If a visual library is your warehouse and a moodboard is your style compass, a research packet is your brief-aligned playbook.

For concepting-side mecha artists, research packets reduce blank-page anxiety and prevent expensive rework. They help you ideate inside the right sandbox: faction values, operational context, technology assumptions, and believable mechanism logic. For production-side mecha artists, research packets prevent “interpretation drift” across modeling, rigging, materials, VFX, and outsourcing. They also create ethical and legal safety: sources are tracked, sensitive reference is handled responsibly, and consultants are credited appropriately.

A research packet is especially valuable in mecha because mecha is systems design disguised as drawing. The packet is where you align the system.

What a mecha research packet contains (at minimum)

At minimum, a mecha research packet includes three pillars: taxonomy, spec notes, and credits. Taxonomy defines the language and categories of the world. Spec notes define assumptions, constraints, and measurable targets. Credits define provenance: where research came from, what was consulted, and who contributed.

You can expand beyond these pillars, but if you skip them, the packet becomes vague. A mecha team cannot stay consistent on “vibe” alone; they need shared labels, shared limits, and shared accountability.

Taxonomy: building a shared language that scales

Taxonomy is how you prevent a team from describing the same thing five different ways. In practice, taxonomy is a structured naming and categorization system for the mecha ecosystem. It should be written in simple language so it works across disciplines.

A good taxonomy usually includes categories for roles, chassis families, subsystems, and variants. Roles describe mission function: loader, scout, siege, escort, breacher, salvage, reconnaissance, firefighting, courier, medical evac. Chassis families describe standardized bodies: “Type-03 Light Frame,” “Type-12 Heavy Hauler,” “Type-21 Amphibious.” Subsystems describe swappable modules: sensor pods, power units, weapon mounts, manipulator arms, armor kits, mobility kits.

For concepting, taxonomy helps you generate ideas quickly. If you know the world has three chassis families and five module kits, you can produce variants that feel like they belong to the same manufacturer or faction. For production, taxonomy is a gift: it supports consistent file naming, asset tracking, modular modeling, and clearer communication in tickets and handoffs.

Taxonomy also prevents accidental contradictions. If the packet states that “all corporate units share a standardized hip block and power coupling,” then every concept should reinforce that. When exceptions exist (a prototype, a stolen unit, a retrofit), the taxonomy makes the exception meaningful rather than accidental.

Spec notes: turning research into decisions the team can build

Spec notes are where your research becomes constraints and targets. They translate “it feels heavy” into “it needs a wide stance, visible counterbalance, and slower acceleration animation.” They translate “it’s futuristic” into “composite outer shells, hidden fasteners, and heat-managed vents.”

Spec notes should be divided into design intent and production constraints. Design intent includes the fictional logic: operational environment, threat model, maintenance culture, and manufacturing philosophy. Production constraints include practical needs: camera distances, readability, rating/tone boundaries, performance targets, and modularity requirements.

For concepting-side artists, spec notes keep ideation aligned. They prevent you from designing a beautiful mechanism that contradicts the world rules. For production-side artists, spec notes reduce rework. If the packet states that “joint covers must never intersect the silhouette in TPP,” then modeling and rigging can plan accordingly.

The best spec notes include “non-goals.” If the game is not about realistic military simulation, say so. If the project avoids real-world insignias, say so. If the style prioritizes bold surfaces over micro greebles, say so. Non-goals protect time and reduce disagreement.

Fieldwork: how to gather data that belongs in a packet

Fieldwork is one of the highest-value inputs for a research packet because it produces evidence you can’t easily get from curated images. For mecha, fieldwork is especially useful for spec notes about maintenance and operation.

When you do fieldwork, don’t just collect “cool shots.” Collect answers to packet questions: Where do humans stand? How do they climb? Where do panels open? What are common warning label patterns? How do hoses route to allow motion? Where does grime collect? What parts show repeated tool contact?

These observations become spec notes like “access ladders and handholds must exist on units above X meters,” or “service panels cluster near joints and power routing,” or “wear is highest at steps, grips, and modular swap points.”

Ethically, fieldwork requires clear boundaries. Use public access areas, respect posted rules, and avoid capturing sensitive information. If you photograph anything that could be proprietary or security-relevant, treat it as private study material and do not distribute it broadly. A good packet can summarize the principle without exposing the sensitive photo.

Archives: how to use manuals, museums, and catalogs without misusing them

Archives are the second major input for research packets because they give you structured information: diagrams, part naming conventions, standardization systems, and historical context. Manuals show how machines are maintained; catalogs show how parts are sold and grouped; museums show how design evolved.

The packet should not reproduce large chunks of archival material. Instead, it should extract learnings and convert them into design rules. You might reference that you studied a set of maintenance diagrams and then write: “service access uses standardized latches; fasteners cluster on removable plates; panel seams align to structural members.”

When using patents or proprietary documents, be careful. Patents can inspire mechanism logic, but avoid making them the blueprint for your fictional design. If the archive source is clearly proprietary or restricted, do not include it in shared packets; summarize the idea in a generic way and cite the source privately if needed.

Ethics: provenance, consent, and “safe inspiration”

A research packet is one of the best places to demonstrate ethical practice because it formalizes what many artists do informally. Ethical research has three core elements: provenance, consent, and abstraction.

Provenance means you track where information came from. Even if you don’t list every link, you record source categories (museum exhibit, field photos, manual type, academic book) and you note anything with restrictions. Consent means you respect permissions: photography rules, NDA boundaries, and consultant agreements. Abstraction means you translate sources into principles rather than copying shapes.

The ethical line is clearest when you compare two packets. A risky packet includes one iconic mecha illustration and then designs that mirror it. A safe packet includes multiple references and then writes explicit principles that can generate new designs. The packet should encourage triangulation: “do not design from a single image; combine at least three sources per subsystem.”

If the project touches cultural symbols, the packet should include a note about cultural responsibility: what is allowed, what is avoided, and who was consulted. This protects the team from unintentional harm and saves time later.

Consultant credits: how to credit without overclaiming

If your project uses consultants—engineers, mechanics, military advisors, cultural consultants, accessibility consultants—your packet should include a credits section. Credits are not only polite; they create accountability and clarify what was actually reviewed.

A good credits section states who contributed, their role, and the scope. For example: “Reviewed actuator plausibility for shoulder assemblies,” or “Advised on safety labeling conventions,” or “Consulted on cultural motif usage and do-not-use symbols.” Be careful not to overclaim expertise. If someone gave general feedback, don’t imply they approved every design.

Consultant credits also help downstream teams. If a question arises later, the team knows who to ask and what the consultant’s domain was. This prevents rumor-based design decisions.

Ethically, only list consultants with permission, and respect privacy requests. Some consultants prefer not to be public. In those cases, you can note the role without naming.

Making the packet usable in concepting and production

A research packet should be readable under deadline stress. That means short sections, consistent headings, and clear takeaways. Concepting artists need fast constraints they can sketch against. Production artists need stable rules they can build against.

One effective approach is to include “decision summaries” at the end of each section. For taxonomy, summarize the naming system and variant logic. For spec notes, summarize the top constraints and non-goals. For ethics, summarize reference rules and do-not-use items. These summaries prevent misinterpretation.

It also helps to include a small set of “gold references” that are safe to share: your own field photos (where permitted), public-domain museum imagery (where allowed), and generalized diagrams you drew yourself based on multiple sources. When you include any external imagery, respect licensing and usage rules, and keep the packet internal if licensing is unclear.

Practical packet content: what to write that actually helps

A useful packet often includes short guidance that concept artists can apply immediately. Instead of saying “industrial,” specify what industrial means in this world: exposed fasteners, modular panels, standardized warning labels, visible lift points, and wear concentrated at touch points.

Instead of saying “military,” specify what military means here: sensor priority, armor layering, redundancy, low-profile protrusions, and repair logic under threat. Instead of saying “sci-fi,” specify whether it’s sleek corporate future (hidden seams, composite shells) or rugged frontier future (patched modules, visible repairs).

Spec notes can also include scale assumptions: approximate height ranges, doorway constraints, cockpit access, and how units relate to human scale. For gameplay, include camera expectations: how much silhouette must read at distance, where emissives are allowed, and where color contrast should be reserved for telegraphs.

The packet becomes most powerful when it includes a few “pattern sentences” that artists can reuse: “All units share a standardized hip block; role identity lives in shoulder modules and backpack kits.” Or: “Detail density clusters around joints and service panels; broad armor plates remain clean for readability.”

Risk management: legal, licensing, and internal boundaries

Research packets can accidentally become a legal risk if they contain copyrighted images used beyond fair internal reference, proprietary diagrams, or restricted photography. A safe packet distinguishes between “internal study” and “shareable reference.”

If you’re in production, set a rule: only include images you have the right to share internally, and be cautious with third-party concept art. If you include it for study, keep it within the smallest necessary group and avoid distributing it to vendors unless explicitly permitted.

A packet can also include a simple internal boundary statement: “This document is for internal use. Do not distribute externally. Do not forward to vendors without approval.” This protects artists who might otherwise share casually.

Updating the packet: treat it like a living style contract

Packets are not one-and-done. They should evolve as the project evolves. Early packets focus on exploration and broad constraints. Later packets focus on lock decisions and standardization. When changes happen—new faction rules, new gameplay constraints, a revised rating target—the packet should capture the change so teams don’t rely on outdated assumptions.

A simple update habit is to add a short “change log” at the top: what changed, why, and how it impacts art. This is especially helpful for outsourcing and for new team members onboarding mid-project.

Closing: research packets as creative freedom with guardrails

A research packet is not a leash; it’s creative freedom with guardrails. When taxonomy is clear, you can generate endless variants that still feel like they belong. When spec notes are explicit, you can design boldly without breaking the world’s rules or the production pipeline. When ethics and credits are handled properly, you protect the team and honor the people and sources that made the work possible.

For mecha concept artists, research packets are a professional superpower. They turn research into speed, speed into consistency, and consistency into a world that feels real—whether your mecha leans industrial, military, construction, sci-fi, anime, western, or a deliberate blend of all of them.