Updated AI prompts

prompts/companies.md

@@ -1,35 +1,52 @@
 Write a factual article for a computer‑museum website about the company or enterprise specified at the end of this prompt.
+
 Use only verifiable information from Wikipedia, period magazines, manuals, corporate filings, and reputable computer‑museum or archival websites.
-Do not invent or infer any detail that is not explicitly documented.
+Do not invent or infer any detail that is not explicitly documented in the sources.
+We are writing a new article, not copying Wikipedia, so use a variety of sources and do not rely too heavily on any single one.
+
+Museum‑grade multi‑source requirement:
+The article must synthesize information from multiple independent, reputable sources, such as period magazines, manuals, archival documents, corporate filings, and museum collections. No single source may dominate the narrative, structure, or factual basis of the article.
+When multiple sources disagree, present only what is verifiably documented and avoid resolving contradictions unless a source explicitly does so.
+If all surviving information originates from a single source, you must state this explicitly in the article and restrict the content to what that source documents, without extrapolation or inference.
+The resulting article must read as a historical synthesis, not a reformatted version of any one reference.
 
 The article should include the following topics when information is available:
-- Founding history: origins, founders, motivations, and early context
-- Corporate mission, initial goals, and the market needs it aimed to address
-- Key design or strategic decisions that shaped its products or services
-- Major technological, architectural, or business innovations introduced by the company
-- Important product lines, platforms, or services (only those directly relevant to the company’s identity)
-- Announcement and launch details for major milestones (how, when, where)
-- Impact at the time of announcement, launch, and throughout the company’s operational life
-- Influence on computing history, the market, users, competitors, and industry standards
-- Standards the company followed, contributed to, or created
-- Corporate structure, acquisitions, mergers, or reorganizations (only if documented)
-- Geographic markets served and regional differences (only if relevant)
-- Financial context when available: launch pricing of key products, major funding rounds, or notable economic events
-- Workforce, culture, and developer or partner ecosystem (only if documented)
-- Decline, transformation, or dissolution (if applicable)
-- Legacy and long‑term historical significance
+- Founding history
+- Corporate mission and early goals
+- Key design or strategic decisions
+- Major technological, architectural, or business innovations
+- Important product lines, platforms, or services
+- Announcement and launch details for major milestones
+- Impact at announcement, launch, and throughout the company’s operational life
+- Influence on computing history, markets, users, competitors, and standards
+- Standards followed, contributed to, or created
+- Corporate structure, acquisitions, mergers, reorganizations
+- Geographic markets and regional differences
+- Financial context (pricing, funding rounds, economic events)
+- Workforce, culture, and developer or partner ecosystem
+- Decline, transformation, or dissolution
+- Legacy and long‑term significance
 
-Requirements:
-- Use prose for all sections; no schematics.
-- If information is unavailable, omit it entirely—do not speculate or create content.
-- Use clear, separated sections, but you may choose the section titles.
-- Use common, professional language suitable for a museum audience; avoid unnecessary technical jargon.
-- Output clean, raw Markdown suitable for direct publication.
-- No emojis. No images.
-- You may cite non‑Wikipedia sources using Markdown reference-style citations.
-- Tables are allowed when appropriate (e.g., timelines, product families, corporate structure).
-- Focus strictly on the specific company requested. Do not discuss unrelated subsidiaries, successors, or predecessor companies unless directly relevant.
-- If a regional branch or subsidiary is requested, restrict the article to that region’s specifics and ignore global variants.
-- Use inline citations and references
+Citation and reference requirements (STRICT):
+- Inline Markdown reference-style footnotes only.
+- Each footnote corresponds to one reference entry with one real URL.
+- No placeholders, no duplicates, no uncited references.
+- Canonical URLs only; parameter variants count as duplicates.
 
-Now write the article about: XXXXXXXXXXXX
+Uniqueness and deduplication rules (VERY STRICT):
+- Deduplicate all sources internally before writing.
+- No repeated URLs in the References section.
+- Multiple statements from the same source must reuse the same footnote key.
+- Do not create new keys for the same URL.
+- The number of references must equal the number of unique URLs.
+- No more than one reference entry per URL, domain, or page.
+- URLs differing only by parameters or fragments count as identical.
+
+General requirements:
+- Prose only; no schematics.
+- Tables allowed when appropriate.
+- Omit any section with no documented information.
+- Clean, raw Markdown. No emojis. No images.
+- Focus strictly on the specific company requested.
+
+Now write the article about: XXXXXXXXXXXX

prompts/machine.md

@@ -1,34 +1,58 @@
+Write a factual article for a computer‑museum website about the hardware machine specified at the end of this prompt. 
+This includes computers, consoles, tablets, PDAs, arcade boards, GPUs, sound synthesizers, and other classes of computing hardware.
 
-Write a factual article for a computer‑museum website about the machine specified at the end of this prompt.
-Use only verifiable information from Wikipedia, magazines, manuals, and reputable computer‑museum or archival websites.
-Do not invent or infer any detail that is not explicitly documented.
+Use only verifiable information from Wikipedia, period magazines, manuals, corporate filings, and reputable computer‑museum or archival websites.
+Do not invent or infer any detail that is not explicitly documented in the sources.
+We are writing a new article, not copying Wikipedia, so use a variety of sources and do not rely too heavily on any single one.
+
+Museum‑grade multi‑source requirement:
+The article must synthesize information from multiple independent, reputable sources, such as period magazines, manuals, archival documents, corporate filings, and museum collections. No single source may dominate the narrative, structure, or factual basis of the article.
+When multiple sources disagree, present only what is verifiably documented and avoid resolving contradictions unless a source explicitly does so.
+If all surviving information originates from a single source, you must state this explicitly in the article and restrict the content to what that source documents, without extrapolation or inference.
+The resulting article must read as a historical synthesis, not a reformatted version of any one reference.
 
 The article should include the following topics when information is available:
-- History
+- History and origins of the machine
 - Design: what the machine is, how it works, and why its manufacturer chose that design
 - Component decisions made by the manufacturer
 - Reasons the manufacturer created it
 - Announcement: how, when, and where it was announced
 - Launch: how, when, and where it was launched
 - Impact at announcement, at launch, throughout its commercial life, and in later historical perspective
-- Technical specifications (use schematics/tables only in this section)
-- Variants (only if it is a family/series; ignore unrelated product lines)
-- Standards it followed and standards it introduced
+- Major technological, architectural, or business innovations introduced by the machine
+- Technical specifications (tables/schematics allowed only here)
+- Variants (only if it is a family/series)
+- Standards the machine followed, contributed to, or introduced
 - Launch price in different markets
 - Weight and dimensions (only if documented)
-- Software ecosystem: third‑party developer reception, involvement, participation, or decline
+- Software ecosystem
 - Legacy
 
-Requirements:
-- Use prose for all sections except Technical Specifications, where tables/schematics are allowed.
-- If information is unavailable, omit it entirely—do not speculate or create content.
-- Use clear, separated sections, but you may choose the section titles.
-- Use common, professional language suitable for a museum audience; avoid unnecessary technical jargon.
-- Output clean, raw Markdown suitable for direct publication.
-- No emojis. No images.
-- You may cite non‑Wikipedia sources using Markdown reference-style citations.
-- Tables are allowed.
-- Focus strictly on the specific machine requested. Do not discuss successors, predecessors, or unrelated variants.
-- If a regional version is requested, restrict the article to that region’s specifics and ignore all others.
+Citation and reference requirements (STRICT):
+- All citations must be inline Markdown reference-style citations, e.g. “...released in 1982.[^ref1]”
+- Each citation must correspond to a single entry in a “References” section at the end of the article.
+- Each entry must be a Markdown reference definition of the form:
+  [^ref1]: https://example.com/page
+- Do not include bibliographic metadata, titles, authors, or publication details.
+- Do not wrap citation sentences in Markdown link syntax.
+- Every reference must contain a real URL. No placeholders, no empty links.
+- Only one URL per reference key.
+- Do not include any references not explicitly cited in the article body.
+- Do not include uncited references.
 
-Now write the article about: XXXXXXXXXXXX
+Uniqueness and deduplication rules (VERY STRICT):
+- Before writing the article, internally deduplicate all sources.
+- The References section must contain no repeated URLs, even if cited multiple times.
+- If multiple statements rely on the same source, they must all cite the same footnote key.
+- Do not create new footnote keys for the same URL.
+- The total number of references must equal the number of unique URLs used.
+- Do not generate more than one reference entry for any single URL, domain, or page.
+- Treat URLs that differ only by parameters, fragments, or tracking codes as identical; use only the canonical one.
+
+General requirements:
+- Prose for all sections except Technical Specifications.
+- Omit any section with no documented information.
+- Clean, raw Markdown. No emojis. No images.
+- Focus strictly on the specific machine requested.
+
+Now write the article about: XXXXXXXXXXXX

prompts/person.md

@@ -1,33 +1,60 @@
-Write a factual article for a computer‑museum website about the person specified at the end of this prompt.
-Use only verifiable information from Wikipedia, period magazines, manuals, interviews, archival documents, and reputable museum or historical websites.
-Do not invent or infer any detail that is not explicitly documented.
+Write a factual article for a computer‑museum website about the person specified at the end of this prompt. 
+This includes engineers, programmers, designers, researchers, executives, inventors, and other individuals relevant to computing history.
+
+Use only verifiable information from Wikipedia, period magazines, manuals, corporate filings, interviews, academic papers, and reputable computer‑museum or archival websites.
+Do not invent or infer any detail that is not explicitly documented in the sources.
+We are writing a new article, not copying Wikipedia, so use a variety of sources and do not rely too heavily on any single one.
+
+Museum‑grade multi‑source requirement:
+The article must synthesize information from multiple independent, reputable sources, such as period journalism, manuals, archival documents, corporate filings, interviews, and museum collections. No single source may dominate the narrative, structure, or factual basis of the article.
+When multiple sources disagree, present only what is verifiably documented and avoid resolving contradictions unless a source explicitly does so.
+If all surviving information originates from a single source, you must state this explicitly in the article and restrict the content to what that source documents, without extrapolation or inference.
+The resulting article must read as a historical synthesis, not a reformatted version of any one reference.
 
 The article should include the following topics when information is available:
-- Early life and background (only documented facts; no speculation)
+- Early life and background (only if documented)
 - Education and formative influences
-- Early career and entry into computing or related fields
-- Key roles, positions, and responsibilities throughout their career
-- Major contributions to computing, engineering, design, research, or industry
-- Motivations behind their work, when documented
-- Important projects, products, or technologies they created, led, or influenced
-- How, when, and where major announcements or milestones involving them occurred
-- Impact of their work at the time and in later historical perspective
-- Influence on computing history, the market, users, competitors, or standards
-- Collaborators, teams, or organizations they were associated with
-- Awards, recognitions, or notable public reception
-- Later life, career transitions, or retirement (only if documented)
+- Entry into computing or related fields
+- Key roles, positions, or affiliations
+- Major projects, products, or research contributions
+- Motivations, design philosophies, or technical approaches (only if documented)
+- Announcement and launch details for major works (how, when, where)
+- Impact at the time of their contributions and in later historical perspective
+- Influence on computing history, markets, users, competitors, or standards
+- Collaborators, teams, or organizations they worked with
+- Awards, recognition, or notable public commentary (only if documented)
+- Later career, transformation, or retirement (if applicable)
 - Legacy and long‑term historical significance
 
-Requirements:
-- Use prose for all sections; no schematics.
-- If information is unavailable, omit it entirely—do not speculate or create content.
-- Use clear, separated sections, but you may choose the section titles.
+Citation and reference requirements (STRICT):
+- All citations must be inline Markdown reference-style citations, e.g. “...she joined the project in 1984.[^ref1]”
+- Each citation must correspond to a single entry in a “References” section at the end of the article.
+- Each entry must be a Markdown reference definition of the form:
+  [^ref1]: https://example.com/page
+- Do not include bibliographic metadata, titles, authors, or publication details.
+- Do not wrap citation sentences in Markdown link syntax.
+- Every reference must contain a real URL. No placeholders, no empty links.
+- Only one URL per reference key.
+- Do not include any references not explicitly cited in the article body.
+- Do not include uncited references.
+
+Uniqueness and deduplication rules (VERY STRICT):
+- Before writing the article, internally deduplicate all sources.
+- The References section must contain no repeated URLs, even if cited multiple times.
+- If multiple statements rely on the same source, they must all cite the same footnote key.
+- Do not create new footnote keys for the same URL.
+- The total number of references must equal the number of unique URLs used.
+- Do not generate more than one reference entry for any single URL, domain, or page.
+- Treat URLs that differ only by parameters, fragments, or tracking codes as identical; use only the canonical one.
+
+General requirements:
+- Use continuous prose; no schematics.
+- Tables are allowed when appropriate (e.g., timelines, roles, affiliations).
+- If information is unavailable, omit the section entirely—do not speculate.
+- Use clear, separated sections; you may choose the section titles.
 - Use common, professional language suitable for a museum audience; avoid unnecessary technical jargon.
 - Output clean, raw Markdown suitable for direct publication.
 - No emojis. No images.
-- You may cite non‑Wikipedia sources using Markdown reference-style citations.
-- Tables are allowed when appropriate (e.g., timelines, positions held).
-- Focus strictly on the specific person requested. Do not discuss unrelated individuals unless directly relevant.
-- If the request specifies a particular period of their life (e.g., “their time at Xerox PARC”), restrict the article to that period and omit unrelated eras.
+- Focus strictly on the specific person requested. Do not discuss unrelated individuals unless directly relevant to the subject’s documented work.
 
 Now write the article about: XXXXXXXXXXXX

prompts/software.md

@@ -1,28 +1,55 @@
 Write a factual article for a computer‑museum website about the software specified at the end of this prompt.
-Use only verifiable information from Wikipedia, magazines, manuals, and other reliable public sources.
-Do not invent or infer anything not explicitly documented.
 
-Optional topics (include only when information is available):
+Use only verifiable information from Wikipedia, period magazines, manuals, corporate filings, and reputable computer‑museum or archival websites.
+Do not invent or infer any detail that is not explicitly documented in the sources.
+We are writing a new article, not copying Wikipedia, so use a variety of sources and do not rely too heavily on any single one.
+
+Museum‑grade multi‑source requirement:
+The article must synthesize information from multiple independent, reputable sources, such as period magazines, manuals, archival documents, corporate filings, and museum collections. No single source may dominate the narrative, structure, or factual basis of the article.
+When multiple sources disagree, present only what is verifiably documented and avoid resolving contradictions unless a source explicitly does so.
+If all surviving information originates from a single source, you must state this explicitly in the article and restrict the content to what that source documents, without extrapolation or inference.
+The resulting article must read as a historical synthesis, not a reformatted version of any one reference.
+
+The article should include the following topics when information is available:
 - History and development timeline
 - What the software is and what it does
-- Origins and motivations behind its creation
+- Origins, motivations, and early context
 - Reasons its developers created it
-- Announcement details (how, when, where)
-- Launch details (how, when, where)
-- Impact at announcement and at launch
-- Influence on computing, the market, users, competing products, or later software
+- Key design, architectural, or strategic decisions
+- Major innovations introduced by the software
+- Announcement details
+- Launch details
+- Impact at announcement, launch, and throughout its active life
+- Influence on computing, the market, users, competitors, or later software
+- Standards followed, contributed to, or introduced
+- Geographic or regional differences (if relevant)
+- Financial context (pricing, licensing, funding)
+- Developer or community ecosystem
+- Decline, transformation, or discontinuation
 - Legacy
 
-Requirements:
-- Use continuous prose; no schematics unless absolutely unavoidable.
-- If information is unavailable, omit the section entirely—do not speculate.
-- Use clear, separated sections, but you may choose the section titles.
-- Use common, professional language suitable for a museum audience; avoid unnecessary technical jargon.
-- Output clean, raw Markdown suitable for direct publication.
-- No emojis. No images.
-- Tables are allowed.
-- You may cite non‑Wikipedia sources using Markdown reference-style citations.
-- Focus strictly on the specific software version requested. Ignore predecessors, successors, or unrelated variants.
-- If a regional version is requested, focus exclusively on that region and omit global variants.
+Citation and reference requirements (STRICT):
+- All citations must be inline Markdown reference-style citations.
+- Each citation must correspond to a single entry in a “References” section.
+- Each entry must be a Markdown reference definition with a single real URL.
+- No placeholders, no empty links, no text-only citations.
+- Only one URL per reference key.
+- No uncited references.
 
-Now write the article about: XXXXXXXXXXXX
+Uniqueness and deduplication rules (VERY STRICT):
+- Deduplicate all sources internally before writing.
+- No repeated URLs in the References section.
+- Multiple statements from the same source must reuse the same footnote key.
+- Do not create new keys for the same URL.
+- The number of references must equal the number of unique URLs.
+- No more than one reference entry per URL, domain, or page.
+- URLs differing only by parameters or fragments count as identical.
+
+General requirements:
+- Continuous prose; no schematics.
+- Tables allowed when appropriate.
+- Omit any section with no documented information.
+- Clean, raw Markdown. No emojis. No images.
+- Focus strictly on the specific software version requested.
+
+Now write the article about: XXXXXXXXXXXX