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
+- Founding history
-- Corporate mission, initial goals, and the market needs it aimed to address
+- Corporate mission and early goals
-- Key design or strategic decisions that shaped its products or services
+- Key design or strategic decisions
-- Major technological, architectural, or business innovations introduced by the company
+- Major technological, architectural, or business innovations
-- Important product lines, platforms, or services (only those directly relevant to the company’s identity)
+- Important product lines, platforms, or services
-- Announcement and launch details for major milestones (how, when, where)
+- Announcement and launch details for major milestones
-- Impact at the time of announcement, launch, and throughout the company’s operational life
+- Impact at announcement, launch, and throughout the company’s operational life
-- Influence on computing history, the market, users, competitors, and industry standards
+- Influence on computing history, markets, users, competitors, and standards
-- Standards the company followed, contributed to, or created
+- Standards followed, contributed to, or created
-- Corporate structure, acquisitions, mergers, or reorganizations (only if documented)
+- Corporate structure, acquisitions, mergers, reorganizations
-- Geographic markets served and regional differences (only if relevant)
+- Geographic markets and regional differences
-- Financial context when available: launch pricing of key products, major funding rounds, or notable economic events
+- Financial context (pricing, funding rounds, economic events)
-- Workforce, culture, and developer or partner ecosystem (only if documented)
+- Workforce, culture, and developer or partner ecosystem
-- Decline, transformation, or dissolution (if applicable)
+- Decline, transformation, or dissolution
-- Legacy and long‑term historical significance
+- Legacy and long‑term significance
 
-Requirements:
+Citation and reference requirements (STRICT):
-- Use prose for all sections; no schematics.
+- Inline Markdown reference-style footnotes only.
-- If information is unavailable, omit it entirely—do not speculate or create content.
+- Each footnote corresponds to one reference entry with one real URL.
-- Use clear, separated sections, but you may choose the section titles.
+- No placeholders, no duplicates, no uncited references.
-- Use common, professional language suitable for a museum audience; avoid unnecessary technical jargon.
+- Canonical URLs only; parameter variants count as duplicates.
-- Output clean, raw Markdown suitable for direct publication.
+
-- No emojis. No images.
+Uniqueness and deduplication rules (VERY STRICT):
-- You may cite non‑Wikipedia sources using Markdown reference-style citations.
+- Deduplicate all sources internally before writing.
-- Tables are allowed when appropriate (e.g., timelines, product families, corporate structure).
+- No repeated URLs in the References section.
-- Focus strictly on the specific company requested. Do not discuss unrelated subsidiaries, successors, or predecessor companies unless directly relevant.
+- Multiple statements from the same source must reuse the same footnote key.
-- If a regional branch or subsidiary is requested, restrict the article to that region’s specifics and ignore global variants.
+- Do not create new keys for the same URL.
-- Use inline citations and references
+- 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, period magazines, manuals, corporate filings, and reputable computer‑museum or archival websites.
-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 in the sources.
-Do not invent or infer any detail that is not explicitly documented.
+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)
+- Major technological, architectural, or business innovations introduced by the machine
-- Variants (only if it is a family/series; ignore unrelated product lines)
+- Technical specifications (tables/schematics allowed only here)
-- Standards it followed and standards it introduced
+- 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:
+Citation and reference requirements (STRICT):
-- Use prose for all sections except Technical Specifications, where tables/schematics are allowed.
+- All citations must be inline Markdown reference-style citations, e.g. “...released in 1982.[^ref1]”
-- If information is unavailable, omit it entirely—do not speculate or create content.
+- Each citation must correspond to a single entry in a “References” section at the end of the article.
-- Use clear, separated sections, but you may choose the section titles.
+- Each entry must be a Markdown reference definition of the form:
-- Use common, professional language suitable for a museum audience; avoid unnecessary technical jargon.
+  [^ref1]: https://example.com/page
-- Output clean, raw Markdown suitable for direct publication.
+- Do not include bibliographic metadata, titles, authors, or publication details.
-- No emojis. No images.
+- Do not wrap citation sentences in Markdown link syntax.
-- You may cite non‑Wikipedia sources using Markdown reference-style citations.
+- Every reference must contain a real URL. No placeholders, no empty links.
-- Tables are allowed.
+- Only one URL per reference key.
-- Focus strictly on the specific machine requested. Do not discuss successors, predecessors, or unrelated variants.
+- Do not include any references not explicitly cited in the article body.
-- If a regional version is requested, restrict the article to that region’s specifics and ignore all others.
+- 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:
+- 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.
+This includes engineers, programmers, designers, researchers, executives, inventors, and other individuals relevant to computing history.
-Do not invent or infer any detail that is not explicitly documented.
+
+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
+- Entry into computing or related fields
-- Key roles, positions, and responsibilities throughout their career
+- Key roles, positions, or affiliations
-- Major contributions to computing, engineering, design, research, or industry
+- Major projects, products, or research contributions
-- Motivations behind their work, when documented
+- Motivations, design philosophies, or technical approaches (only if documented)
-- Important projects, products, or technologies they created, led, or influenced
+- Announcement and launch details for major works (how, when, where)
-- How, when, and where major announcements or milestones involving them occurred
+- Impact at the time of their contributions and in later historical perspective
-- Impact of their work at the time and in later historical perspective
+- Influence on computing history, markets, users, competitors, or standards
-- Influence on computing history, the market, users, competitors, or standards
+- Collaborators, teams, or organizations they worked with
-- Collaborators, teams, or organizations they were associated with
+- Awards, recognition, or notable public commentary (only if documented)
-- Awards, recognitions, or notable public reception
+- Later career, transformation, or retirement (if applicable)
-- Later life, career transitions, or retirement (only if documented)
 - Legacy and long‑term historical significance
 
-Requirements:
+Citation and reference requirements (STRICT):
-- Use prose for all sections; no schematics.
+- All citations must be inline Markdown reference-style citations, e.g. “...she joined the project in 1984.[^ref1]”
-- If information is unavailable, omit it entirely—do not speculate or create content.
+- Each citation must correspond to a single entry in a “References” section at the end of the article.
-- Use clear, separated sections, but you may choose the section titles.
+- 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.
+- Focus strictly on the specific person requested. Do not discuss unrelated individuals unless directly relevant to the subject’s documented work.
-- 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.
 
 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)
+- Key design, architectural, or strategic decisions
-- Launch details (how, when, where)
+- Major innovations introduced by the software
-- Impact at announcement and at launch
+- Announcement details
-- Influence on computing, the market, users, competing products, or later software
+- 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:
+Citation and reference requirements (STRICT):
-- Use continuous prose; no schematics unless absolutely unavoidable.
+- All citations must be inline Markdown reference-style citations.
-- If information is unavailable, omit the section entirely—do not speculate.
+- Each citation must correspond to a single entry in a “References” section.
-- Use clear, separated sections, but you may choose the section titles.
+- Each entry must be a Markdown reference definition with a single real URL.
-- Use common, professional language suitable for a museum audience; avoid unnecessary technical jargon.
+- No placeholders, no empty links, no text-only citations.
-- Output clean, raw Markdown suitable for direct publication.
+- Only one URL per reference key.
-- No emojis. No images.
+- No uncited references.
-- Tables are allowed.
+
-- You may cite non‑Wikipedia sources using Markdown reference-style citations.
+Uniqueness and deduplication rules (VERY STRICT):
-- Focus strictly on the specific software version requested. Ignore predecessors, successors, or unrelated variants.
+- Deduplicate all sources internally before writing.
-- If a regional version is requested, focus exclusively on that region and omit global variants.
+- 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