Trust is a record of evidence, not a badge on a page.

Gritnox is an independently developed product concept demonstrating industrial parts discovery and procurement workflows. The application combines a purpose-built catalog and RFQ experience with session-authenticated buyer, seller and administrator workspaces, checkout and order operations in the same codebase.

The seeded manufacturers, suppliers, parts, equipment models, offers and compatibility records are fictional or illustrative. Interface labels identify the catalog as demo data; the underlying records also carry demonstration metadata where the model supports it.

• No supplier is contacted by a demo RFQ and no commercial commitment is created.
• No manufacturer endorsement, partnership, certification or audit is represented.
• No live price, stock, warranty or lead-time accuracy is claimed for the illustrative offers.
• References to real-world standards or component categories do not imply authorization from their owners.

Cross-references use separate relationship types because equivalent, superseded, interchangeable and replacement references are not synonyms. Review the type before substituting a component.

A supplier offer includes fields that cannot be collapsed into part identity: seller, supplier SKU, condition, price and currency, minimum order quantity, stock state, lead time, warranty and last-confirmed time. Mixed currencies remain separate rather than being converted into a misleading rank.

• The published-offer minimum is used only for ordering; it is not presented as a universal market price.
• Stock and lead-time values describe the demo record and may not represent current supplier inventory.
• Offer freshness is shown so that an older confirmation is not confused with a live quote.
• A part can have no published offer. That is a valid state, not a reason to fabricate availability.

• Public RFQ and contact submissions are validated and rate-limited at the API boundary.
• Authentication uses an HttpOnly Django session with CSRF-protected writes; authorization is enforced by API permissions and scoped querysets.
• Seller applications require a verified email. Storefront activation is a separate administrator decision and is blocked for unapproved, inactive or suspended sellers.
• The public catalog and demo intake do not require payment credentials.
• The project has not completed an independent penetration test, compliance certification or production security review.
• Operators deploying this code must replace demo credentials, configure HTTPS, restrict hosts and review secrets before exposure.

• Do not present demo records as live supplier inventory, certifications or commercial relationships.
• Do not use similarity, a shared dimension or a descriptive title as proof of interchangeability.
• Do not strip evidence labels when exporting or screenshotting catalog records.
• Do not use the platform to misrepresent an unauthorized part as manufacturer-approved.
• Keep the demo boundary visible when showing the project to a commercial audience.

For a data-correction, accessibility or security concern, use the contact form and select the closest topic. The form records a validated request with a reference, but it is not a staffed incident-response channel.

Operators deploying a real service must replace this demo intake with documented contact, incident-response and data-retention procedures. See the project documentation for the current implementation boundary.