This policy sets out who is responsible for RazFit editorial content. It also explains how we choose sources, what happens when a page needs correcting, and where general fitness information stops being useful. The policy applies to articles, guides, comparisons, exercise explainers, and programmatic editorial pages on razfit.app. None of those formats turns general information into personal medical advice.

The short version is this: RazFit publishes the content, and RazFit Team is the collective editorial signature. We check health and fitness claims against identifiable sources, keep source metadata with the page, and use repository checks to catch missing attribution, contradictory identifiers, and stale update dates. RazFit Team is not presented as an individual clinician, and a RazFit byline does not mean that a doctor or other licensed professional reviewed the page. The site’s content model defaults editorial pages to RazFit Team, while the organization schema identifies RazFit as the organization behind the site.

Who publishes the work

RazFit is the publisher of razfit.app and the developer of the RazFit app. The website uses one stable organization identity for the publisher, and the product configuration points to the public RazFit listing on Apple’s App Store.

RazFit Team is a collective byline. It tells you that the page was prepared and maintained under RazFit’s editorial process; it does not identify a natural person. We will not attach a person’s name, qualifications, professional registration, or review credit unless that person really participated and we can verify the description. The current collection schemas use RazFit Team as the default author for both blog and programmatic content.

An attributed quotation or paraphrase from an outside specialist has a different job. It identifies the source of a particular statement. It does not make that person the author, editor, or reviewer of the whole page. Our content model keeps the person’s name, role or credentials when supplied, and the source URL alongside the attribution.

We currently do not claim routine human medical review of every article. There is no standing medical-review board represented in the editorial article schema, and the default brand author is RazFit Team. If we introduce a genuine review step later, we will identify the reviewer, describe the scope of the review, show the review date, and update this policy. We will not add a medical-review label merely to make a page look more authoritative.

What this policy covers

This policy covers editorial material on razfit.app: blog posts, programmatic guides, comparisons, workout explainers, source lists, visible author information, and the structured metadata used to describe those pages. Product help, privacy notices, and legal terms have their own purposes. A product-support answer may explain how to use RazFit, while an editorial article may discuss research or general training choices. Neither is a substitute for care from a qualified professional who knows the reader’s circumstances.

RazFit’s site configuration contains 18 supported locales. Blog content can be available across those 18 locales, while programmatic and resource collections currently use a smaller declared subset. A translated route is not evidence that every article exists in every language. We publish a localized page only when the route, copy, metadata, and editorial checks for that locale are ready.

This policy itself is intended to be available in all 18 site locales. The English version is the source version for the first publication wave. Localized versions must preserve the same publisher model, health limits, correction route, and disclosures, but they should read as natural writing in the target language rather than as line-by-line translations.

How we choose sources

For a health, exercise, or safety claim, we start with the source most capable of supporting the exact statement. Sometimes that is an official guideline; sometimes it is the original paper or a systematic review. Product behavior and rules usually call for documentation from the organization responsible for them. A secondary article can help explain context, but it should not replace an accessible primary source merely because it is easier to quote.

Our choice depends on the claim. A guideline is normally the better source for a public recommendation. An original trial may be appropriate for what happened in one studied population. A systematic review can describe the direction and limits of a body of research. Product behavior should come from first-party product information or direct verification. We do not treat a prestigious domain, a long bibliography, or a familiar institution as proof that a source answers the question on the page.

Before we use a source, we check its identity, what population or subject it covers, the date, and whether the page’s wording stays within the source’s scope. When relevant, we also check the study design, comparison, outcome, duration, limitations, and whether later guidance has replaced it. If the available evidence does not support a precise claim, we narrow the wording, add the uncertainty, or remove the claim. We do not fill the gap with an unattributed phrase such as “research shows.”

The repository has a content-quality gate, V39, that checks programmatic pages for source lists, attributed expert material, update dates, citations near H2 sections, vague claims, excessive hedging, boilerplate, and truncated copy. This automated gate supports editorial review; it cannot decide whether advice is suitable for one person’s medical history.

The source-checking sequence

For new or materially revised health content, our working sequence is:

Identify the claim that needs support and write down its intended scope.
Open the source itself, not only a search snippet or another page’s summary.
Confirm the title, author or issuing body, publication date, and durable identifier or canonical URL.
Read enough of the source to check population, method, outcome, and important limitations.
Write the claim in words that do not go beyond that evidence.
Put the source near the relevant passage and include it in the page’s structured source data where the page format supports it.
Run the relevant content, metadata, traceability, and freshness checks before publication.

This is a bounded process, not a promise that every scientific question has one settled answer. Different study designs can produce different kinds of evidence. A result in a supervised clinical sample may not transfer to an unsupervised home workout. An association does not establish causation. A statistically significant average does not tell an individual exactly what will happen. Those distinctions belong in the copy whenever they affect a reader’s decision.

PMID and DOI handling

A PubMed identifier (PMID) identifies a record in PubMed. A digital object identifier (DOI) identifies a scholarly object through the DOI system. They help us distinguish sources with similar titles and reduce metadata drift, but neither identifier proves that the study is strong, relevant, or correctly interpreted.

When a programmatic source uses a PubMed URL or declares a PMID, our source inventory retains the identifier separately from the visible URL. It does the same for a DOI. That separation lets the validator detect contradictions between an explicit identifier and the identifier encoded in the URL.

V40 is RazFit’s offline source-metadata contract for programmatic content. It loads the source inventory, the local PMID registry, and the associated debt baselines, then delegates metadata comparison to a shared evaluator. The shared rules require verified registry entries and compare source metadata such as title, author, publication, date, and DOI.

This check runs without fetching PubMed during a normal site validation. Offline operation matters because a build should not become a claim of verification merely because a network request happened to succeed. Registry synchronization is a separate maintenance action. An identifier mismatch, a new unregistered PMID, or contradictory metadata must be resolved or explicitly handled under the repository’s ratchet rules before it is allowed to blend into existing debt.

We may cite useful sources that have no PMID or DOI. Official guidance, standards, public documentation, and product pages often use ordinary URLs. In those cases, we still record a clear title and canonical destination, check the issuing organization, and make sure the body actually uses the source. Missing identifiers should not be replaced with invented ones.

Keeping citations connected to claims

A references list is useful only if readers can tell what each source supports. RazFit’s policy is to place a source in the same passage or nearby section as the material claim whenever the page format allows it. A distant list of six studies does not, by itself, show which study supports a statement about duration, population, risk, or expected outcome.

V63 checks this connection for published programmatic pages. It recognises a declared source through its URL, PMID, DOI, author surname, or sufficiently distinctive title terms, then reports sources that are declared but not cited in the visible content. It also checks that the source attached to an expert attribution exists in the page’s source list.

Traceability is not the same as scientific accuracy. A page can point to the correct paper and still exaggerate the conclusion. For that reason, an editor must compare the wording with the source’s scope after the automated check passes. We also distinguish direct quotations from paraphrases. Quotation marks are reserved for words we can verify as verbatim; a summary should be described and written as a paraphrase.

If a source link later breaks, we look for the canonical replacement or an archived official location. We do not quietly point the citation at a different document with a similar title. If the replacement changes the evidence behind the passage, that is a material editorial update and the text should be reviewed again.

Updates, dates, and corrections

The publication date tells you when a page first appeared. The update date is meant to signal a meaningful change to the visible editorial material, not a routine rebuild, formatting adjustment, or automatic date refresh. RazFit content schemas store publication and update dates as YYYY-MM-DD values.

V64 compares the visible-content projection of each published programmatic record with an append-only freshness baseline. The validator is intentionally offline and passes only when the current programmatic corpus and baseline are synchronized. This makes an unexplained material change to that corpus observable during validation; it does not mean every unchanged page is still current enough for every topic, and it does not extend the V64 contract to blog or policy content.

We review a page when we discover an error, a cited source is withdrawn or materially corrected, new official guidance changes the practical answer, product behavior changes, or a reader gives us specific evidence that the page is wrong. The urgency depends on likely harm. A wrong safety instruction takes priority over a broken stylistic detail.

For a substantive correction, we will change the affected passage, recheck its sources and nearby claims, update the visible modification date, and rerun the applicable validators. When the correction materially changes what a reader should do or believe, we will add a clear correction note or otherwise make the change understandable on the page. We will not use a newer date merely to make old content appear fresh.

Small edits are treated differently. Fixing punctuation, correcting a harmless typo, changing whitespace, or updating non-editorial code does not normally justify a new editorial update date. If a small-looking edit changes meaning, a number, a contraindication, a source, or a destination link, it is material and must go through the substantive path.

Localization and language QA

RazFit supports readers across 18 configured locales, but localization is an editorial task rather than a mechanical string replacement. A localized page should use natural terminology for its audience and retain the same evidence, safety boundaries, product facts, and commercial disclosures as its source version.

Our localization sequence is to lock the verified meaning in the source version, adapt the wording for the target locale, check links and metadata, compare material claims with the source ledger, and obtain a separate language QA review before publication. We do not count an English fallback as a completed translation. If an exact medical or legal term has no clean everyday equivalent, the localized copy should favour clarity and define the term rather than imitate the English sentence.

Units, date formats, decimal conventions, health-system references, and product availability can vary by market. A translator or reviewer should change those details only when the localized statement remains true and supported. Local adaptation is not permission to introduce a new dosage, training threshold, legal promise, or product feature. A new material claim needs its own evidence check.

Localized pages can be updated at different times when the evidence or required correction differs. Still, a safety correction that applies across languages should trigger a review of every affected locale. We will track the affected routes rather than assume that changing the English page automatically repairs its translations.

Medical and fitness boundaries

RazFit content provides general educational information about exercise, fitness habits, and related research. It cannot assess symptoms, diagnose a condition, prescribe treatment, clear someone for exercise, or account for an individual’s medical history, medication, pregnancy, disability, recovery, or environment. A reader who needs an individual decision should speak with an appropriately qualified professional. The editorial schema describes the material as an article published by RazFit; it does not declare a clinical service or routine medical reviewer.

Exercise involves risk. The level and type of risk depend on the person, activity, intensity, technique, surroundings, and health context. We therefore avoid universal promises such as “safe for everyone,” guaranteed outcomes, or a single plan that is suitable in every circumstance. Instructions should include meaningful limits where the source or topic calls for them, without turning every paragraph into a vague disclaimer.

Content about a condition is not a treatment plan. A page may summarize evidence about exercise in a studied population, but it must state when supervision, screening, or individual adaptation was part of that evidence. It must not imply that an app replaces emergency services, clinical assessment, physiotherapy, mental-health care, or another regulated service.

If someone has chest pain, severe breathing difficulty, loss of consciousness, signs of a medical emergency, or another urgent concern, a website article is the wrong tool. They should contact local emergency services or seek urgent professional help. Because emergency numbers and care pathways differ by country, RazFit does not publish one universal contact number in this global policy.

The absence of a warning on a particular page is not proof that an exercise is appropriate for a particular reader. Equally, a general caution is not a diagnosis. We aim to give readers enough context to recognise when a general article stops being useful and an individual assessment becomes necessary.

Commercial interests, funding, and conflicts

RazFit publishes editorial content on the same site that markets the RazFit app. Some pages link to the app’s commercial App Store listing, and the destination is held in central site configuration. Readers should assume that RazFit can benefit when editorial content leads to interest in or use of the app.

That commercial interest must not be hidden behind the editorial byline. We do not describe RazFit Team as independent from RazFit. We also do not claim outside funding, editorial independence, or financial relationships that are not documented. If a future page is sponsored, paid for by a third party, based on supplied products, or written under another material arrangement, we will disclose that relationship where readers can see it.

A link to RazFit is not evidence for a health claim. Product pages can support statements about the app’s own documented behavior, while health and safety statements need sources suited to those claims. We will not rank a source more favourably because it makes the product easier to sell. Comparisons should state the criteria being used and avoid presenting RazFit as the universal choice.

The site’s commercial purpose also affects calls to action. A button that opens the App Store should be recognisable as a product link, not disguised as a medical recommendation or a source citation. Editorial access should not depend on clicking it.

How to report a concern

Specific reports are the easiest to investigate. Please include the page URL, the passage you believe is wrong, why it may be wrong, and a source if you have one. Do not send private medical records or other sensitive health information.

For an editorial correction, source question, attribution concern, or general policy question, email hello@razfit.app. For help using the RazFit app or an account-related product issue, email support@razfit.app. For a privacy request or question about personal data, email privacy@razfit.app.

We will triage a report according to the potential effect on readers. We may ask for clarification, compare the passage with its cited source, check other locales that reuse the claim, and record a correction when the evidence warrants one. We cannot discuss another person’s account or private information with an unauthorised reporter.

This policy is itself subject to correction. When we materially change the publisher model, health boundaries, source process, localization requirements, commercial disclosure, or contact route, we will update the effective date and review every localized version. Historical Git records may show the technical change, but the public policy should remain understandable without asking a reader to inspect the repository.

A practical reading rule

Before relying on an article, check who published it and whether the important claims lead to sources that genuinely support them. Look at the date, too. Then ask the harder question: does this general information fit your situation, or has the page reached the point where individual advice is needed? RazFit’s byline, citations, dates, and this policy are there to make that check easier. They are not seals of certainty.

When a page gives a general training option, use its evidence and limitations to decide whether the option is worth discussing or trying. When the decision depends on symptoms, diagnosis, medication, injury, pregnancy, or another personal clinical factor, stop at that boundary and seek individual advice. For questions about the wording or evidence on RazFit, use the editorial contact above. For app operation, use support.