Maintenance teams
Plant and maintenance engineers who need to identify a replacement part from a reference, machine model or failure context.
Independent product concept
Industrial procurement needs better evidence, not more listings.
Gritnox is a product concept for industrial parts discovery and procurement. It explores how canonical part records, equipment fitment evidence and supplier-specific offers can coexist without pretending that one record proves everything about another.
Product concept & engineering by Zisanur Haque. Gritnox is not an operating marketplace and is not affiliated with any manufacturer or supplier shown in the demo catalog.
The problem
A part number is only the beginning
Industrial buyers often work across fragmented catalogs, informal supplier references and equipment documentation that does not share a common identity model.
A search result can look plausible while the underlying part is wrong. A supplier can list a compatible replacement while leaving the condition, warranty or lead time unclear. An equipment model can have multiple variants that change the correct part.
Those are different kinds of uncertainty. Treating them as a single “verified” badge hides the decisions a procurement team actually needs to make.
The approach
Separate identity, evidence and commerce
Gritnox keeps three questions distinct: what the part is, whether it fits a machine, and what a supplier is currently offering.
01
Canonical identity
Manufacturer, primary part number, alternate identifiers and typed attributes describe the catalog record.
02
Fitment evidence
Equipment relationships carry a status and evidence reference instead of inheriting credibility from the catalog record.
03
Commercial offers
Each supplier offer keeps its own SKU, condition, price, currency, MOQ, stock state, lead time and confirmation time.
Intended users
Designed for people who have to get the part right
The concept focuses on professional procurement contexts where a wrong match has operational cost.
Procurement teams
Buyers who need a reviewable request with quantities, delivery requirements and technical notes rather than an immediate checkout.
Small manufacturers
Operations with mixed equipment fleets and limited visibility into which supplier references may correspond to the same component.
Industrial suppliers
Distributors who need to publish offer conditions while keeping price, stock, warranty and lead time separate from catalog identity.
Current capability
A coherent first vertical slice
The initial implementation focuses on part discovery through RFQ submission instead of a broad collection of disconnected screens.
01
Identifier-led discovery
Part numbers, alternate references, internal SKUs and supplier references are searchable, with exact identifiers ranked ahead of descriptive matches.
02
Structured specifications
Typed attributes preserve units and value types. Descriptive text remains available without pretending that prose is a specification.
03
Evidence-aware fitment
Equipment relationships carry a status, relationship type, evidence reference and review context. Similarity is not promoted to verification.
04
Offer comparison
Published offers expose condition, price and currency, MOQ, stock, lead time, warranty and confirmation freshness without collapsing mixed currencies.
05
Sourcing list to RFQ
A local sourcing list captures parts and quantities. The RFQ workflow records buyer and delivery details in a separate procurement request.
06
Explicit demo state
Illustrative records, offers and suppliers are labelled in the interface and in the underlying data model where practical.
Catalog status
Illustrative data, deliberately limited.
The current catalog is a small seeded dataset built to demonstrate search ranking, filtering, evidence states, offer comparison and RFQ submission. Manufacturers, suppliers, equipment models and offers are fictional. No supplier has been contacted, no inventory is represented as live and no commercial relationship is implied.
The demo is intentionally not a full production marketplace. Supplier onboarding, live pricing feeds, authentication for procurement roles and operational order fulfilment remain outside this first vertical slice.
What is real in this build
- Catalog models, search, filters and part detail are backed by the Django API.
- Fitment evidence statuses are persisted and exposed in the interface.
- Sourcing lists are stored locally in the browser.
- RFQ submissions are persisted with a generated reference and validated server-side.
- Existing authentication, vendor and order flows are inherited from the original marketplace codebase.
Data & evidence policy
What the interface will not claim
These rules are part of the product design, not a disclaimer added after the fact.
No automatic verification
Matching attributes or a similar description never upgrades a fitment to verified. Verification requires a recorded evidence reference and review context.
No implied supplier authority
A published offer does not mean the supplier is manufacturer-authorised, that the part is genuine, or that stock is live.
No invented commercial proof
The demo does not display fabricated revenue, customer logos, testimonials, certifications or partnerships.
No hidden currency comparison
Offers in different currencies are not reduced to a misleading lowest price.
No compatibility by name alone
Cross-reference relationships describe how records relate; they do not automatically establish interchangeability.
No silent demo data
Illustrative records and offers are labelled in both the catalog surface and the project documentation.
The demo catalog is a design and engineering fixture. It must not be used to select, purchase or install a real industrial part.
Follow the workflow
Start with a reference. Finish with a reviewable request.
Try an exact identifier, inspect its evidence, compare demo offers and submit an RFQ without creating an order.