Version: 2.1.0
Updated: 20 October 2026
Audience: contributors, editors, translators, LLMs and coding agents.

Read this before writing or rewriting public text. The visual styleguide defines colours, typography, components, technical-tool exceptions and preview layouts. It replaces the separate visual-direction tutorial. These two documents govern new copy and design; older examples are not permission to repeat outdated claims.

1. Identity and responsibilities

Ghostmaxxing is independent free software for experimenting with face-recognition camouflage. It includes browser tools, modular visual interventions called Ghostyles, a technical and cultural archive, and optional public gallery/Fediverse infrastructure.

The project comes from politically engaged hacking: inquiry, subversion and freedom. It challenges the normalisation of biometric surveillance. Explain that position through experiments, documented deployments and inspectable methods. Do not reduce the audience to technical insiders or describe the software as an invisibility product.

Ghòstati! is the initiative of NINA's Universal Union, called Sindacato Universale di NINA in Italian. Keep the name Ghòstati! in both languages. The Union organises its workshops and manages its confidential whistleblowing channels. Ghostmaxxing supplies software that NINA and other organisations can use.

NINA is an external integrator of Ghostmaxxing. Hosting the lab does not make NINA the operator of Ghostmaxxing's public upload service. A public gallery submission is not a confidential report. Attribute each action to the organisation receiving it.

Ready-to-use attribution:

Ghostmaxxing develops the software. Ghòstati!, part of NINA's Universal Union, organises workshops and handles confidential reporting.

Use maintained destinations rather than copying questionnaires, Onion Service addresses, Signal invitations or security instructions:

Check these destinations when publishing. The Union blog covers other initiatives too: do not relabel it the official Ghostmaxxing software blog. Sindacato's editorial pages use Ghòstati! as the initiative name; software attribution belongs where it helps explain a technical integration, not in every workshop heading.

2. Instructions for writers and agents

Apply these rules to headings, navigation, body copy, metadata, social cards and outreach drafts.

1. Lead with an action or finding. Say what the reader can test, inspect, reproduce or contribute.
2. Use a subject and a verb. Prefer “The browser compares two descriptors” to “The facilitation of biometric comparability”.
3. Keep one main point per sentence. Most sentences should fit in 12 to 25 words. Split sentences that combine a feature, its politics, a limitation and a future ambition.
4. Do not use em dashes in new prose. Use full stops, commas, colons or parentheses. Preserve exact quotations, source titles and identifiers.
5. Remove abstract hyperbole. Do not call the work revolutionary, groundbreaking, transformative, unprecedented, game-changing or the future of privacy. A quoted claim needs attribution and a reason to include it.
6. Remove statements that sound profound but specify nothing. Replace “the order is the contract” with the actual colour roles. Replace “where identity meets resistance” with what people do.
7. Avoid stock LLM wording. Do not use “delve”, “unlock”, “seamlessly”, “empower”, “foster” or “leverage” instead of an explanation. Use technical terms only when their object and meaning are clear.
8. Avoid rhetorical padding. No “This isn't just X, it's Y”, “More than a tool”, invented question-and-answer hooks, or final slogans repeating the introduction. Genuine research questions should name a testable unknown.
9. Name actions and recipients. “Open the lab”, “Save a baseline”, “Read NINA's reporting guidance”. Avoid “Discover the possibilities” and “Leak to us” on a software page that sends users elsewhere.
10. Place limitations beside claims. Name the model, task and conditions that matter. Do not repair an unsupported headline with a generic disclaimer at the bottom.
11. Do not invent evidence. No invented efficacy, partners, adoption figures, quotes, measurements or deployed features. Put missing evidence in an editorial note outside publishable copy.
12. Preserve the argument. Do not neutralise criticism of biometric surveillance, add marketing excitement, or rewrite precise technical names for variety. Use clear international English; UK and US spelling may coexist.
13. Use formatting for comprehension. Sentence-case headings; lists for steps; tables for comparisons; no emoji in core copy and no bold emphasis on every line.
14. Translate responsibilities as well as words. The organisation, destination, consent boundary and limitation must mean the same thing in both languages. Never translate Ghòstati! into Ghostmaxxing.

Concrete rewrites

Humour is welcome when it names a specific situation and remains understandable internationally. Keep consent, errors and reporting instructions literal. Do not make people decipher a joke before deciding where their data goes.

3. Claims and technical vocabulary

Separate detection (finding a face), landmarks (estimating geometry), matching (comparing representations) and identification (assigning identity against a collection). They are not interchangeable.

• face-api descriptors concern face matching. State which comparison and threshold the interface uses.
• MediaPipe Face Landmarker estimates geometry; do not describe landmarks alone as identity recognition.
• MediaPipe ImageEmbedder with MobileNetV3 produces generic image embeddings. Do not call them biometric face descriptors.
• A Ghostyle is a modular visual intervention that can be applied and retested. A digital overlay does not establish that physical makeup will reproduce the result.
• “No face”, “model loading”, “camera denied” and “model failed” are different states. A missing result is not a successful intervention.
• A green display, changed distance or interrupted detection is not evidence of safety against deployed surveillance.

Keep the research loop concrete: run a local experiment; document conditions; share suitable material with consent; let others reproduce or challenge it; revise tests and archive entries. NINA's workshops can reuse the tools. Confidential evidence follows NINA's separate process. Do not imply reports enter the public gallery or automatically become Fediverse posts.

Use Fediverse integration as the short navigation label. “Fediverse native integration” can be used in an explanation that identifies ActivityPub functionality. Explain implemented publication, actors and moderation; do not promise automatic inbound lab updates unless implemented and verified. Federation transports public objects; it does not make them trustworthy.

Current short tool labels: Camouflage lab, Video analyser, Makeup Explorer. Use “Makeup Explorer” for realtime.html; explain its measurements in the page introduction. Use Open lab for the main action. Do not rename exported functions, routes or technical model names to match a display label.

4. Outreach and external descriptions

Ready-to-use descriptions

Short:

Ghostmaxxing is free software for testing face-recognition camouflage in the browser and documenting results under stated conditions.

Technical:

Ghostmaxxing combines browser-based visual interventions, local comparisons and a research archive. Its tools let people inspect model outputs and document experiments. Results depend on the model and test conditions; a browser test does not establish protection against deployed systems.

Workshop:

Ghòstati!, part of NINA's Universal Union, runs workshops using Ghostmaxxing's browser tools. Participants compare visual interventions and discuss what the measurements can and cannot show.

Writing for other sites and communities

• Lead with the relevant method, reproducible observation or open question. For a technical audience, link code and test conditions. For a workshop audience, explain activities, prerequisites, organiser and consent choices.
• Link the software name to https://ghostmaxxing.vecna.eu/ and source code to https://github.com/vecna/ghostmaxxing. Link a specific tool or record when that is the subject.
• Attribute research to its authors. Distinguish a paper's reported result from an independent reproduction and from a proposed experiment.
• Do not turn a software integration, article or independent review into a partnership or endorsement. Name the host and software separately.
• Keep concrete uncertainty in excerpts and social posts too. Do not let the short version make a broader claim than the article.
• Use participant images only with appropriate permission for that specific publication. Retain credits and context. Do not expose private receipts, faces from confidential reports or identifying metadata in previews.
• A pitch is not a press release: explain why the work fits that audience, what can be inspected now and what remains unresolved. Avoid identical promotional paragraphs sent everywhere.

These are attribution and editorial rules, not additional software licence terms. Consult the repository licence for redistribution obligations.

5. Search, previews and structured data

Metadata is public copy. Review it with the visible page whenever identity, responsibility, routes or claims change.

• Give each public page a specific title, for example Makeup Explorer | Ghostmaxxing, and a description of the actual task. Aim for roughly 45 to 65 title characters and 120 to 160 description characters where useful; these are editing targets, not protocol limits or display guarantees.
• Align <title>, description, Open Graph, Twitter card text and JSON-LD with the visible content. Avoid unsupported efficacy and stale workshop ownership in all of them.
• Use absolute HTTPS public URLs for canonical URLs, og:url, preview images and structured-data identities. Do not publish localhost, preview-server or filesystem paths.
• Set the document language. Add hreflang only between actual equivalent translations; a generic language homepage is not the translation of a specific article.
• Use the structured-data type that describes the page, such as SoftwareApplication for software or Article for an article. Name the actual author, publisher and host; do not add invented ratings, dates or NINA ownership of the software. Keep stable entity IDs where the entity is the same.
• og:image:alt and image dimensions describe the actual file. A visual label should remain understandable when cropped; alt text describes rather than repeating a slogan.

Preview pictures

Edit scripts-dev/social-cards.html; use the existing generator, for example:

node scripts-dev/build-social-cards.cjs --only generic

The generator supports landscape 1200 × 630, square 1200 × 1200 and wide 1500 × 500 variants. Verify the relevant options before changing a workflow. Review outputs in images/social/ and cards-manifest.json, then update page metadata separately. Generation does not automatically fix every page's tags.

Use one short title, one factual sentence, the mark and a relevant image or camera composition. Keep important text and faces away from crop edges. Follow the visual styleguide for token use. Do not show fabricated numerical results or imply that a decorative spent lens proves a test succeeded. Review both full-size export and thumbnail; check crops in the receiving platform when possible.

Sitemap and indexing

web-files/sitemap.xml is a maintained source file copied into the served output by the client installer. npm run htmls does not automatically discover pages and regenerate it.

Include absolute canonical URLs for public pages intended for indexing. Remove deleted routes and exclude internal guides, previews, private receipt fragments and duplicate variants. Use meaningful modification dates; a routine rebuild is not a content update. Keep the sitemap declaration in robots.txt aligned with the deployed site.

At the reviewed commit, the sitemap needs a separate audit for realtime.html and its functional guide. This documentation update does not modify that sitemap. Keep visual-styleguide.html marked noindex; do not add it to the sitemap. A sitemap is a discovery hint, not a guarantee of indexing.

6. External hosting and backend boundaries

A host may serve the tool's HTML, CSS, JavaScript, vendor files and models under its own path. Keep relative asset paths valid, preserve attribution where appropriate and avoid changing the backend just because the frontend origin changes.

lab-js/backend-url.js is the routing source of truth:

Use the helper for public backend operations rather than maintaining another hostname switch. Local development requires the backend to be running for those operations. Do not rewrite public upload/gallery endpoints to the external host's /api by accident.

Explain these boundaries to users at the relevant action:

• The frontend host serves the interface and its assets. Running an inference locally is distinct from loading those resources over the network.
• Comparisons run in the browser. Optional uploads and public gallery/media operations use Ghostmaxxing's backend.
• Receipt links and local receipt storage belong to the frontend origin/path used by the participant. Do not promise they transfer between the upstream site and a mirror. Do not publish receipt links or deletion tokens in metadata, logs or screenshots.
• NINA's confidential reporting is separate. Link its maintained guidance; never submit reports through the gallery API.

Example disclosure for a host, adapting the first sentence to the actual organisation:

This site hosts the Ghostmaxxing interface. Comparisons run in your browser. If you choose to upload a recording, it is sent to Ghostmaxxing's service at ghostmaxxing.vecna.eu. Ghòstati! workshops and confidential reporting are managed separately by NINA's Universal Union.

Before publishing a hosted copy, verify HTTPS and camera access, asset/model loading under the final path, backend CORS for the actual origin and required methods/headers, and any CSP restrictions. For framed inclusion, verify camera permissions and frame policies. Prefer a direct link or native hosting when a frame adds permission problems.

Test upload consent, gallery fetch and deletion from the deployed origin using disposable test media. Confirm the deletion request's X-Delete-Token header is permitted where required. Do not infer that a backend accepts a mirror merely because local inference works.

<<<<<<< Updated upstream One line: Ghostmaxxing is free software for browser-based experiments with face-recognition camouflage and the technical and cultural history of anti-biometric interventions.

Short: Ghostmaxxing combines local camera experiments, modular AR interventions called Ghostyles, comparison tools and a reference archive. Results describe a particular model and test setup. Optional gallery submissions are separate from NINA's confidential reporting channels.

Extended: Ghostmaxxing lets developers, researchers, artists, digital rights groups and curious people inspect how visual interventions change a browser pipeline's outputs. Ghostyles make interventions reproducible; the archive helps readers trace earlier demonstrations and their limits. People can choose to submit media for moderation and possible public distribution through the gallery and Fediverse. Ghòstati!, part of NINA's Universal Union, organises workshops and receives confidential evidence about real-world deployments through separate channels.

Technical accuracy

Distinguish the task before describing a result:

Feature extraction produces an embedding/descriptor; avoid teaching these as two independent recognition stages. Scores from different engines are not interchangeable. A missing detection, a failed match, an unready model and an error are different states. Explain the actual label, model, threshold and conditions rather than translating all of them into “success”.

Evidence and claims

For a result, record the task, model/version, intervention, comparison baseline, threshold and material conditions such as light, camera, pose and distance. Report unsuccessful attempts too. Unknown transfer to another model or deployed system stays unknown.

Prefer “the local matcher did not match the saved descriptor under these conditions” to “your fingerprint is no longer recognised”. Do not equate digital overlays with demonstrated physical makeup performance. Use “defeated” only for a specific documented past result, never a promise.

An archive entry should identify the work, primary source, demonstration, conditions, limitations and what can be retested. Separate an author's claim from our observation.

Research and data flows

1. Run a local experiment and inspect the result.
2. Document the conditions and, where useful, package the intervention as a Ghostyle.
3. Optionally submit selected media for moderation and possible gallery/Fediverse publication.
4. Use public results and archive material to inform further experiments or workshops.
5. Refer people with confidential evidence to NINA's separate guidance.

These are related activities, not one automatic pipeline. Do not imply that confidential reports flow into the gallery, or that verified reports automatically become software updates. Any later public use of findings needs a separate editorial decision by the responsible organisation.

Describe implemented publishing and feeds using fediverse.html and the backend contract. Bidirectional ingestion of federated research objects or automatic installation of Ghostyles must be labelled as a proposal unless the particular feature has been verified. Do not infer deployment health from source code or a roadmap.

“Local processing” describes the experiment's processing path. It does not mean that opening the website makes no network requests, that optional uploads stay local, or that all media metadata is removed. Use the current upload and privacy explanations, not an absolute “nothing ever leaves your device”.

Names and invitations

A Ghostyle is a modular visual intervention applied through the lab. Define it at first mention for a general audience. A plugin can reproduce an intervention; it does not certify protection. Use “filter” only when the cosmetic/rendering sense is intended.

Existing chrome may still say “Leak to us”. Treat that as legacy wording to review in templates and translations, not a phrase to prescribe in new copy. A link label should make the recipient clear without implying that clicking it submits a report.

On Sindacato, the initiative keeps the name Ghòstati! in both languages. Links opening its native lab use a new tab as agreed for that integration; software navigation may continue to Ghostmaxxing. This is an integration choice, not a requirement to open every external link in a new tab.

Tone by surface

• Homepage and About: invite exploration; explain software scope and the NINA relationship.
• Lab: next action, processing location, model state and limits. No manifesto during a task.
• Technical docs: prerequisites, interfaces and reproducible examples. No persuasive claims in API contracts.
• Archive and genealogy: evidence, provenance and chronology. A dated project marker is not a victory over a whole class of systems.
• Fediverse: concise updates with test conditions and publication context. Distinguish public objects from confidential material.
• Workshop/report links: welcoming or calm as appropriate; identify NINA and let its maintained pages provide practical details.

Mechanics and maintenance

Use clear international English, sentence-case headings and short declarative instructions. Preserve names, identifiers and quoted titles. UK and US spelling may coexist. Define technical terms, put limits next to claims, and avoid emoji and em dashes in new core copy.

Before publishing, check the responsibility, observable feature, evidence and destination. When an engine, upload flow, owner or navigation destination changes, review the affected public text, metadata, translations and this guide in the same change.

Do not copy exact feature inventories or deployment status into all three design documents. This guide owns voice and claim discipline; visual-direction.md owns design intent; visual-styleguide.html shows specimens. Code owns token values and component behaviour. Review on relevant changes rather than assuming a version number makes a document current.

Canonical policy is a deliberate host decision: an unchanged mirror can identify the upstream tool as canonical; a host-specific page intended for indexing can use its own canonical. Keep that choice consistent across canonical, og:url, JSON-LD and sitemap. Sindacato's native Ghòstati! pages use Sindacato URLs for their own identity; backend URLs do not determine page identity.

When Sindacato opens its lab in a separate tab, retain target="_blank" rel="noopener". Make external recipients clear in link text. Do not force every software link to open a new tab.

7. Maintaining the guides

Keep responsibilities and writing rules here; keep design rules and live specimens in /visual-styleguide.html. Exact values belong in CSS, routing in lab-js/backend-url.js, and feature behaviour in implementation and functional documentation. A public page is a reference for wording, not proof of deployment.

When changing a feature, review visible copy, metadata, structured data, preview image, sitemap and both guides where relevant. Record the source commit or release in the review. Do not copy transient item counts or test results into permanent rules.

Useful implementation references:

• styles/tokens.css, styles/cameras.css, styles/chrome.css
• styles/lab.css, styles/realtime.css, styles/loader.css
• lab-js/backend-url.js, lab-js/upload-consent.js, lab-js/gallery.js
• scripts-dev/social-cards.html, scripts-dev/build-social-cards.cjs
• scripts-dev/enrich-jsdoc-seo.cjs, web-files/sitemap.xml

Older generators and tutorials may contain em-dash title suffixes or stale identity rules. This standard governs new output; review those generators explicitly rather than assuming a documentation edit changes them.

8. Extra references

<<<<<<< HEAD

Reporting anonymity and access

Ghostmaxxing may state that its designated GlobaLeaks channel protects source anonymity. The reporting page must explain both access routes:

1. the standard HTTPS address, suitable for ordinary access;
2. the Onion Service v3 address, opened with Tor Browser, for stronger connection anonymity and resistance to selective interception or blocking.

The Tor option must be visible before a person starts a submission. Link to the official Tor Browser download and usage guidance, and display the current Onion Service address from maintained configuration rather than duplicating it across static copy.

Do not extend the anonymity claim beyond the designated reporting system. A source may still reveal identifying information through the content, files, metadata or circumstances of a report. Safety guidance must explain data minimisation and the risks of submitting documents or media.

Reference: https://docs.globaleaks.org/en/stable/technical/security/application-security.html

Vocabulary

Preferred terms

• face recognition
• facial recognition
• face detection
• face matching
• biometric surveillance
• anti-biometric camouflage
• adversarial makeup
• appearance-based intervention
• physical-world attack
• computer vision
• Ghostyle
• reference archive
• testability
• limitations
• local experiment
• browser-based lab
• public research
• public-facing research lab
• reporting node
• civic intelligence
• retest
• adversarial

Use with context

The following terms can be accurate, but should be tied to a specific task, model or result:

• evasion
• spoofing
• attack
• resistance
• surveillance
• anonymisation
• camouflage
• hacking
• defeated

Prefer "a local test of face-matching evasion in a browser pipeline" to "face recognition evasion".

Avoid or heavily qualify

• invisibility
• anonymity guarantee outside the designated GlobaLeaks reporting channel
• protection
• foolproof
• defeat, when used as a general or present-tense claim
• bypass all systems
• anti-surveillance shield
• safe in public
• untrackable
• undetectable

Naming conventions

Project name

Ghostmaxxing names the software, lab, software site and archive. Ghòstati! names NINA’s initiative in both Italian and English. NINA’s Universal Union organises workshops and handles confidential reporting. Keep this distinction in copy and navigation.

Ghostyle

Ghostyle is a term introduced as part of Ghostmaxxing.

A Ghostyle is a modular visual intervention applied to the face through the Ghostmaxxing lab. It is also the unit in which an intervention can be saved, described, tested and shared.

Write:

• Ghostyle
• Ghostyles
• Ghostyle plugin, when referring to the technical format

At first mention for a general audience, use a short definition such as "a modular AR intervention called a Ghostyle".

Avoid:

• filter, unless immediately clarifying that a Ghostyle is a testable intervention rather than only a cosmetic effect;
• effect, unless describing rendering behaviour;
• makeup hack, except in deliberately informal social copy.

Define Ghostyle through its current role in Ghostmaxxing.

Tone by page

Homepage

Tone: direct, visual, activist and concise.
Job: establish the project, the central action and the research loop without front-loading every qualification.
Lead with: a strong, testable proposition.
Avoid: dense institutional background, multiple competing CTAs and protection claims.

Recommended core copy:

Test face-recognition camouflage in the browser. Build Ghostyles, compare detection and matching behaviour, and explore the research behind anti-biometric appearance design.

About

Tone: clear, connective and politically explicit.
Job: explain why the project exists, who it is for and how the theory of change works.
Lead with: the project as a public investigation, then show the bidirectional loop between Ghostyles, the Fediverse backend, anonymous reporting and new tests.
Avoid: a feature inventory, a conventional organisation biography or a claim that awareness alone produces change.

Lab and tool pages

Tone: operational, calm and exact.
Job: help a person run a local experiment and understand what the interface can and cannot measure.
Lead with: the next action, local processing and the current state of the test.
Avoid: manifesto copy during a task, ambiguous controls and claims that a local result transfers to deployed systems.

Ghostyle documentation

Tone: practical, inspectable and collaborative.
Job: define the intervention, its components, provenance, test conditions and limits.
Lead with: what the Ghostyle changes and how to reproduce the test.
Avoid: presenting a Ghostyle as a finished protection product or stripping results from their conditions.

References

Tone: editorial, investigative and evidence-led.
Job: help readers understand lineage, demonstrations, limits and opportunities for retesting.
Lead with: what the source is and what it actually demonstrated.
Avoid: abstract bibliographic language, authority by citation count and implying that a paper result is universal.

Each reference entry should answer:

1. What is this?
2. What did it demonstrate?
3. Under which conditions?
4. Why does it matter?
5. What are its limitations?
6. What can Ghostmaxxing retest?
7. Where is the primary source?

Genealogy

Tone: theatrical at entry, precise in every dossier.
Job: show successive technical eras, documented interruptions and the live present without turning history into a victory narrative.
Lead with: the lineage and how to read the lens states.
Avoid: treating dates as deployment dates when they mark public demonstrations, or implying that one intervention defeated face recognition as a whole.

Reporting node

Tone: calm, serious, specific and non-coercive.
Job: help a person decide whether, what and how to report.
Lead with: source anonymity, scope, safety guidance, data minimisation and the choice between HTTPS and the Onion Service through Tor Browser.
Avoid: urgency theatre, heroic whistleblower language, vague requests for suspicious material and anonymity claims outside the protection actually provided by GlobaLeaks and Tor.

Workshops

Tone: welcoming, concrete and method-led.
Job: explain what participants will do, what they need and what they will leave with.
Lead with: activities, learning outcomes, accessibility and consent.
Avoid: making technical confidence a prerequisite or presenting participants as test subjects.

Fediverse page and social posts

Tone: conversational, observant and concise, while retaining the claims discipline of the site.
Job: explain the implemented Fediverse functions, the target federated data backend and how the lab will receive validated updates from other ActivityPub actors.
Lead with: the objects and updates currently available through the network, then identify planned bidirectional functions clearly. Explain how people and compatible applications can follow, respond or contribute.
Avoid: presenting the Fediverse as a social-media mirror, promotional filler, engagement bait, context-free screenshots and any suggestion that incoming data bypasses moderation.

Technical documentation

Tone: explicit, reproducible and low-ambiguity.
Job: help contributors understand data flow, files, states, limits and contribution rules.
Lead with: prerequisites, observable behaviour and exact terminology.
Avoid: unexplained internal shorthand and persuasive brand language where an implementation rule is needed.

Calls to action

The global primary CTA is Open the lab. The software site's Tools disclosure lists Camouflage lab, Video analyser and Makeup Explorer. Explain the last as “See how makeup changes face descriptors in real time”. Fediverse integration describes the project's publishing infrastructure; it is broader than an invitation to follow one account.

Use Ghòstati! / NINA for the external navigation group. Identify NINA's Universal Union as the organiser of workshops and operator of confidential reporting. Use Confidential reporting at NINA, not “Leak to us”. Label the external editorial destinations Union blog · Italiano and Union blog · English because those blogs cover other initiatives too.

Use ↗ to mark external destinations consistently. It does not mean the link opens a new tab. Keep the agreed Sindacato-to-lab new-tab behaviour; do not impose it on every external link.

Navigation HTML is deliberately copied into pages and generators. See navigation-maintenance.md for the maintenance inventory.

Style and mechanics

• Write clear international English. UK and US spellings may coexist and should not be normalised merely for consistency.
• Preserve the spelling used in code identifiers, source titles, quotations and official names.
• Use the serial comma only where it prevents ambiguity.
• Prefer short declarative sentences around actions, risks and limits.
• Use contractions sparingly in conversational surfaces such as the Fediverse.
• Use sentence case for headings unless a component has another established rule.
• Do not use emoji in the core site voice.
• Do not use em dashes. Use a full stop, colon, comma or parentheses instead.
• Do not use rhetorical questions when a direct statement is clearer.
• Define specialist terms at first use on public pages.
• Put limitations beside the claim they limit.

Publication checklist

Before publishing, ask:

• Are Ghostmaxxing software and the Ghòstati! initiative attributed to their respective owners?
• Is Ghostyle defined on first use for a general audience?
• Does every consequential claim have the right grade?
• Are the test conditions and limits close to the result?
• Does the copy avoid implying safety, invisibility or universal transfer?
• Does the page make its role in the research loop clear?
• Is the reporting request proportionate and accompanied by safety guidance?
• Does the tone match the page type?
• Is the English consistent and free of em dashes?
• Can a non-specialist understand the action without losing technical accuracy? =======

• Reference specifications: Open Graph, Google sitemap guidance, MDN CORS.
• visual styleguide.

Stashed changes brand-voice-update