Research agent prompt

Current research completion instruction — 10 October 2026

The user clarified that research agents must complete their assigned research, not stop after producing a preliminary report and a list of gaps. Earlier bounded-report staffing produced useful reviewed drafts; those are preserved as provenance and are not completed node research.

Continue through fixable gaps. Choose and justify a coherent making method and supported design/material choices, specify the output and its interfaces/capability/acceptance requirements, complete the immediate Parts/Tools inventory and operation stock, allocate meaningful workpiece states and quantities, and resolve independent-review findings. Use primary evidence and explicitly identified engineering derivations; do not invent numerical values, source support, yields or qualification.

Completing a node's research is distinct from making it or researching every descendant to nature. Its required child outputs can remain unmade or unresearched, but their actual required functions, states, interfaces, quantities and capability contracts must be stated. Do not treat unmade workshop stock or an open deeper branch alone as proof the parent research cannot be completed.

Use a flagship reference as a functional benchmark, not an obligation to reproduce inaccessible proprietary OEM drawings. Investigate documented/public alternative architectures that meet the capability target. Routine defensible engineering choices are part of the research; do not leave every choice unselected indefinitely. Genuine unresolved critical evidence, necessary experiments, or an indispensable human constraint must be investigated and recorded as a specific blocker. They cannot be silently removed to earn a completion label.

Independent full-completion review must cover the node specification, selected method, immediate inventory, material/operation accounting, caller compatibility and independent acceptance. A completed document or source-claim review alone does not authorize inventory_complete, spec_reviewed or reviewed-complete route flags. Research activity and saved report/review links must be published to the map through the guarded lifecycle mechanism; active, paused and reviewed-draft records are blue. Green retains the actual complete-reviewed-node criteria and is separate from whole-path manufacturing closure.

Use this template for a bounded topic assignment. The user authorized coordinated bulk discovery and research on 8 October 2026.

Research activity and saved evidence must be published by the worker through the metadata-only lifecycle helper. Read docs/research-publication.md. At actual assignment/start run its activity --state started command with your canonical IDs and section. Mark an explicit pause/block promptly; do not infer completion from file existence. After each actually authored report, save its hash-bound publication manifest and run the helper's publish command so the node page links to the real saved evidence. Preserve immutable report versions and historical review scopes. An independently reviewed preliminary draft remains blue; complete the own-node method/specification/inventory/capability research and obtain independent immediate-record certification before full completion. Unmade descendants are separate from own-node research completeness. This narrow metadata publication is authorized; physical graph changes still follow the shared ownership and gated proposal rules below.

For fast inventory discovery, use discovery-agent-prompt.md. This longer prompt applies to making-page research and evidence review. Discovery workers should submit compact immediate inventories and flags; the coordinator handles record enrichment and publication, while deeper research follows in separate assignments.

Research [item / capability tier / candidate making route] for Smartphone Building. Read the research rules and dependency contract supplied with the task. Assume a knowledgeable group on an Earth untouched by humans, with no manufactured objects, stock materials, facilities or utilities. Research the physical product. Software is a black box: the phone's operating system, firmware, apps and protocol implementation can be installed after import into the real world. Do not research software development, compiler creation or a computing bootstrap for writing software. The final phone must offer modern flagship-equivalent capabilities, charge using a standard external charger, and work on real-world networks. Towers, outlets, external chargers and external carrier services are interface boundaries; they do not supply your workshop.

Preserve the physical prerequisites for loading and running software: compatible chips, memory, boot/loading interfaces, programming fixtures, host hardware, cables and power where necessary. List any manufacturing-control or test program as a black-box software requirement with its function, physical host and availability timing. Software installed only after import cannot operate an earlier fabrication step. Black-box software requirements are boundary metadata, not invented raw-material terminals or software-making dependency chains.

Before proposing dependencies, inspect the latest shared registry, selected routes, capability specifications, aliases, evidence statuses, existing proposals and any build/inventory ledger. Search by function as well as name: a tool made for another task may already perform yours. The coordinator must provide this current context, not just an isolated topic prompt.

At large scale, start with the coordinator's revision-stamped canonical index and the scoped records/routes for your assignment. Search the global index by ID, aliases, function and capability before requesting a new identity; retrieve full records for plausible matches. Do not attempt to fit a registry of tens of thousands of records into a prompt. A scoped slice is context, not permission to invent duplicates outside it. Record the base revision and the exact ownership boundary; shared platform changes need coordination with their owner.

Corrections from the first coordinated discovery pass

• Assign role by actual use and physical identity. Feedstocks and incorporated devices are Parts. Reusable ignition apparatus, firing beds, vessels, fixtures, comparison references and instruments are Tools. A reusable tool is not consumed merely because a generic helper defaulted its role to Part. Requirements must state incorporation, consumption, reuse or verification explicitly.
• Check canonical meaning, not the word alone. Handset electronic storage cannot represent a covered stockpile. A bench audio-amplifier cannot represent incorporated handset speaker-drive electronics without a compatible distinct route and demand. Keep a real reuse explanation for new grades or subassemblies.
• A low-tier wooden grip trial cannot serve a molten-metal pour, molten strengthening bath or ferrite furnace. Do not put an unproved property such as heat resistance into an item's title. Specify actual temperature, chemistry, mass, contact time and grip needs as unknown when unknown; retain incompatible earlier/advanced tiers separately.
• Physical inventories must match the chosen method. Washed fiber needs a vessel as well as water. A soda-lime glass route needs an explicit compatible calcium feed rather than generic ceramic stock. Firing needs fuel, ignition, forming, placement and handling. A populated board needs its mounted active chips, not just a list of loose chips in the handset's parent route.
• Keep route alternatives separate. Wirebond and flip-chip packages, SOI and polysilicon MEMS processes, loose copper pickup and heat-assisted bedrock extraction, dry fiber preparation and washing/retting have different physical obligations. Never combine their ingredients merely because all appear in a source or an older seed list.
• Replacing a selected hypothesis requires replacing its visible inventory and making outline consistently. Preserve older descriptions under explicit prior/provenance fields. Duplicate route IDs must be rejected or replaced deliberately, never silently repeated in an array.
• A declared acyclic frontier may still conceal the eventual first-tool loop. List the unresolved controller, power, metrology or seed-crystal prerequisites, and the blocking eventual dependency. Do not remove a known requirement to make the cycle test pass.
• MEMS devices need specified structural/sacrificial layers, anchors, release and stiction management, cavity sealing/feedthroughs, packaging protection and a coherent release/bond/dice sequence. A patterned silicon wafer or generic ASIC encapsulant is insufficient.
• Preserve manufacturing hierarchy. A final assembly consumes completed modules; its module routes consume their internal chips, sheets, films and subassemblies. Do not flatten every descendant back into the root as another incorporated input or list all upstream factory tools as final-assembly tools. When correcting a flat inventory, keep every known physical requirement reachable through the actual selected consumer; retain unresolved allocation explicitly rather than deleting it. Containment and repeated use are not additional consumed stock.
• Supply readable record metadata as well as graph schema: plain name, Part/Tool role, domain, short function/consumer summary, evidence label, unknowns and provenance. Frontier nodes need these too. A structural gate pass does not verify page-rendering fields or science. If no URL is available, preserve the reference as an unlinked lead; never count a null or invented URL as a checked source. Complete-record upserts must retain the display metadata of prior records.

Discovery scale and reporting

The user expects the eventual physical map to contain tens of thousands of nodes or more. Discovery should expose distinct outputs, material states, independently understandable subassemblies, tools, consumables, utilities and acceptance/calibration equipment throughout the handset and workshop. Do not stop at a generic semiconductor factory, battery machine or chemical workshop label. Expand the contents, then give bounded sections to breadth-first and depth-first owners. Node-count growth is useful scope information, never a numerical completion estimate or a quota to inflate with aliases, duplicate copies, individual atoms or arbitrary process fragments.

Report newly identified canonical outputs, expanded known requirement inventories, the shortest physical levels reached, still-unexpanded frontiers by level/domain, unselected candidate inventories, and new evidence-backed claims separately. The handset is level 0; route records do not count as levels. A long single trail does not establish breadth through level five. Every inventory remains incomplete until an actual review justifies otherwise. Raw occurrence candidates may stop discovery expansion provisionally but cannot close manufacturing paths.

Prefer existing canonical IDs for tools, materials, fixtures, utilities and verification equipment that meet your demands. Compare range, precision, purity, dimensions, interfaces, calibration, environment, contamination, quantity, capacity and availability at your step. An already researched node is not necessarily physically made or qualified; explicitly mark unknown suitability for review. List reused requirements in your own page's inventory even though their manufacture is documented elsewhere. Shared tools can be scheduled across tasks; consumables require enough stock and replenishment. Additional physical copies do not automatically require a new tool design or making page.

Include a reuse assessment for each proposed new dependency: existing candidates checked, why reuse or an adaptation cannot meet the need, and whether a justified earlier/advanced tier or subassembly is required. Propose an alias or extension of an existing record when it is the same item. Do not make five differently named tools for one capability. Do not merge genuinely different purity, precision or contamination states just to reduce node count. Reuse must respect build order: an existing definition whose selected construction depends on your output is not an available prerequisite. Submit that conflict to the code gate and investigate an earlier route.

Produce one bounded making-page proposal and structured node/route proposals in your assigned staging folder. Do not edit the accepted registry, generated website or live dependency links. Use stable IDs supplied by the coordinator; request new IDs explicitly. A citation, return link or containment relation must not be encoded as a manufacturing prerequisite.

Keep the title plain. Put measurable capability requirements and unknown values in the specification header, including every requirement inherited from the caller. Distinguish required quantities, consumables, incorporated parts, reusable tools, facilities/utilities, control software and verification/calibration equipment. List every known physical prerequisite, including apparently ordinary surfaces, containers, leads, connectors, supports, lubricants, handling, environmental controls and process-specific protection. Do not substitute an external link for this inventory.

Describe how inputs become the output, where each tool is used, and what accepts the result. If researching a tool, describe its manufacture and commissioning, leaving instructions for using it in its caller. Split long topics at useful subassembly or operation boundaries, with explicit contents. Track unresolved requirements rather than assuming they exist.

Browse primary sources: official technical documentation, research papers, manufacturer process descriptions, patents, standards or authoritative institutional records. Map each important technical claim to a supporting source and note what that source does not establish. Distinguish source-supported facts, your design inferences and hypotheses. Do not invent numerical tolerances, yields, durations or costs. A demonstration-scale tool is not evidence for the final phone's capability.

Submit physical dependencies as proposals for the central gate. Flag apparent cycles and research at least one credible earlier or simpler route when a dependency introduces a major industry or bootstrap problem. Different names are insufficient: an earlier tier needs distinct capabilities and a route using genuinely earlier tools. Calibration must have an independent reference. Black-box software still needs compatible physical host and loading hardware, but no source-code or binary bootstrap research. Shared output and co-product routes need quantities and compatibility conditions.

For every leaf, say whether it is an unexpanded frontier, blocked requirement, external interface, or candidate natural endpoint. Natural endpoints need evidence of availability, recognition, usable quantity and required collection/transport steps. You cannot approve terminal closure yourself.

Return: proposed page; all known Parts and Tools; structured required IDs and capability demands; reuse assessment and reasons for new IDs; primary sources with claim scope; alternatives and reasons; unknowns; maturity; proposed endpoint status; and priority next actions. Never call a path complete because it has no recorded children. The coordinator checks canonical reuse and a separate reviewer checks suitability before the automatic cycle gate and publication.

• Presentation order for immediate requirements: approximately major Part, major Tool, minor Part, minor Tool relative to the parent. Keep requires rows in that order so map grouping follows it; preserve classifications and all obligations. Existing page order is the starting assumption and can be improved when that page is revised.