Fabric Documentation

The Fabric Trust Index is an open-source, public directory of trust scores for AI tools, models, MCP servers, and API services. Over 5,800 indexed services each receive a composite score from 0.00 to 5.00, computed from 23 independently scored sub-signals grouped into six weighted dimensions — all generated automatically from public data sources. The scoring engine is in active beta and is open source under AGPL-3.0.

Trust Score

The Fabric Trust Score is the core of the Trust Index. It determines whether a service is trusted, flagged for caution, or blocked outright.

Every AI service indexed by Fabric receives a composite score from 0.00 to 5.00, computed from 23 independently scored sub-signals grouped into six weighted dimensions. Each sub-signal scores 0–5 individually, then is combined with its weight within its dimension. The six dimension scores are then multiplied by their respective weights and summed to produce the final composite score.

All scoring data is generated automatically from public sources. No manual reviews. No paid placements. No provider involvement required. A provider doesn't need to opt in — or even know they're being scored — for Fabric to evaluate them.

The six dimensions

Each dimension groups related sub-signals that measure a specific aspect of trust. Dimensions are weighted by risk — security carries more weight than popularity.

1. Vulnerability & Safety ×0.25

The highest-weighted dimension. Measures known security vulnerabilities across the package and its entire dependency tree using the OSV.dev CVE database.

Fabric scans for open CVEs at every severity level — critical, high, medium, and low. Unpatched critical vulnerabilities carry the heaviest penalty and can single-handedly drop a service into Blocked status. Even patched vulnerabilities incur smaller deductions, because they indicate the dependency was once vulnerable. Deductions scale by the square root of CVE count to avoid over-penalising high-CVE packages with many patched issues.

2. Operational Reliability ×0.15

The only dimension generated by Fabric's own infrastructure. We actively ping service endpoints for uptime, latency, error rates, and incident history — no provider can fake this one.

Services with a real, publicly reachable endpoint can achieve the highest scores. Services that only have a registry listing (e.g. an npm page with no live API) are capped below the maximum. Uptime is the primary driver, measured over a rolling 30-day window. Latency is evaluated at the p99 level — we care about worst-case, not average.

Services with no endpoint to monitor (CLI tools, local packages) receive a fallback value rather than zero, which prevents them from being unfairly penalised.

3. Maintenance Activity ×0.15

Is anyone home? Abandoned software is a security risk regardless of how clean the code is today. This dimension captures the human factor behind a project.

Fabric evaluates commit recency, release cadence, issue responsiveness, and CI/CD presence. Recent activity and consistent releases score well. Long periods of inactivity drop the score significantly.

Stable, mature projects with low commit frequency aren't penalised as heavily — release cadence and issue responsiveness carry more weight than raw commit volume. CI/CD presence (GitHub Actions workflows) is a strong signal of professional maintenance practices.

4. Adoption ×0.15

Not a security signal per se, but a strong proxy for how many eyes are on the project. High adoption means more users finding and reporting issues, more pressure to maintain quality, and a larger blast radius if something goes wrong — which motivates faster fixes.

Download volume is scored on logarithmic tiers — this means the difference between 1,000 and 10,000 downloads matters more than the difference between 10 million and 100 million. GitHub stars, download growth velocity, and category normalisation all factor in. Niche tools aren't penalised for being specialised — they're compared against peers in their category.

5. Transparency ×0.15

Can you see what it does before you run it? Open source projects with clear documentation, proper licensing, and published schemas are inherently more trustworthy than black boxes.

Fabric evaluates source code availability, licence type (OSI-approved permissive licences score highest), documentation quality and size, security disclosure practices (SECURITY.md), and changelog presence. AI model categories have additional requirements such as published model cards.

6. Publisher Trust ×0.15

Who built this? A first-time anonymous account publishing a critical infrastructure tool is a very different risk profile than a verified organisation with many other maintained packages.

Fabric evaluates the publisher's organisation maturity (account age, organisation vs. individual), external credibility (followers, total stars across all repos), community standing (number of public repos), cross-platform identity consistency (presence on GitHub, npm, PyPI), and track record across sibling services in the index. Established publishers with long track records and verified organisational presence score highest.

The 23 sub-signals

Each dimension is composed of independently scored sub-signals. Every sub-signal has its own weight within its dimension. On any service's profile page, you can expand each dimension to see exactly which sub-signals contributed to the score.

Vulnerability & Safety ×0.25

Operational Reliability ×0.15

Maintenance Activity ×0.15

Adoption ×0.15

Transparency ×0.15

Publisher Trust ×0.15

How scoring works

The final score is a weighted sum of all six dimensions. Within each dimension, sub-signals are independently scored on a 0–5 scale, combined by their sub-signal weights, and the resulting dimension score is multiplied by the dimension weight. The dimension weights sum to 1.00, producing a final composite score between 0.00 and 5.00.

When a sub-signal has no data (e.g. no PyPI downloads for an npm-only package), its weight is proportionally redistributed to the other sub-signals within the same dimension that do have data. This weight redistribution mechanism replaces the previous fallback value system — it ensures scores are never penalised for missing data, and every score reflects exactly what can be verified.

Score thresholds

Every indexed service falls into one of three tiers based on its composite score. These labels are shown publicly on the Trust Index.

Trusted gate

Achieving Trusted status requires more than just a composite score above 3.00. The scoring engine applies a "trusted gate" — a data sufficiency check that prevents services with insufficient coverage from being labelled trusted prematurely.

To qualify for Trusted status, a service must:

• Have vulnerability data (the vulnerability dimension must have real data, not fallbacks)
• Have at least 4 out of 6 dimensions with real data
• Pass all safety override rules (no active critical CVEs, no deprecated packages, etc.)

If any of these conditions fail, the score is capped at 2.99 and the status is downgraded to Caution, regardless of the raw composite score.

Safety overrides

Beyond standard scoring, Fabric runs seven safety override rules that can force a service's status downward (never upward). These exist because certain conditions represent such severe risk that no combination of other signals should override them.

Vulnerability overrides (3-tier)

Supply chain overrides

Additional overrides

Data freshness

The scoring engine runs on a fixed schedule across all indexed services. Different signals are refreshed at different intervals depending on how quickly the underlying data changes.

When a new CVE is published that affects an indexed package, the fast-path scanner picks it up within 5 minutes and triggers an immediate score recomputation. Most scores reflect data that is at most 24 hours old, with vulnerability data being as fresh as 5 minutes and uptime data refreshed every 15 minutes.

How to read a profile

Every service in the Trust Index has a dedicated profile page. Here's what each section tells you and how to use it.

Score ring

The large circular score at the top right of every profile. The ring fills proportionally to the score (0–5) and is colour-coded by status: Trusted green, Caution orange, or Blocked red. The number in the centre is the composite score to two decimal places. Below it you'll see the status label, a confidence badge (high / medium / low / unverified), and a timestamp showing when the score was last recalculated. A Beta badge indicates the scoring engine is in active beta.

Signal breakdown

Six expandable cards showing each dimension's individual score (0–5) alongside its weight percentage. Click any card to expand it and see the individual sub-signals that contributed to that dimension's score. Each sub-signal shows its name, effective weight (after redistribution), score bar, score number, a detail description, and the data source. Sub-signals without data are clearly marked and show "weight redistributed" — their weight was proportionally distributed to the sub-signals with real data.

About this score

A collapsible section below the signal breakdown showing the total number of sub-signals analysed for this service, the scoring engine version, and the current phase roadmap.

Privacy & compliance grid

A six-cell grid showing binary compliance signals: Training Opt-out, Retention Policy, SOC 2, GDPR, Model Card, and HIPAA. Each cell shows a green checkmark (confirmed), red X (not available), or grey "Unknown" (insufficient data). These are not factored into the trust score — they're supplementary context for your own evaluation.

Incident timeline

A chronological log of notable events affecting the service. Each entry is colour-coded: red for incidents, orange for degradation, blue for updates, and green for resolutions. Where possible, we show the score impact of each event (e.g. "−0.34" after a major outage, "+0.12" after a vulnerability patch). This helps you see how a score has changed over time and why.

Score history chart

A 90-day line chart showing the service's composite score over time. The gradient fill below the line is colour-coded by status. Hover over any point to see the exact score and date. Look for sudden drops (incidents), gradual declines (abandonment), or steady climbs (active improvement).

Community metrics

Aggregate usage data pulled from public sources: total downloads or runs, known integrations with agent frameworks, and community ratings from registries. These numbers provide context for the Adoption dimension — but they're shown separately so you can evaluate them independently.

Data sources

A list of every source we pulled data from to generate this profile's score. Each entry shows the source name and key stats (e.g. "GitHub · 34.2k ★ · 412 contributors"). This is our transparency layer — you can verify any claim by clicking through to the original source.

Categories

Every indexed service is assigned to one of eleven categories. Categories help you filter the directory and compare like-for-like — an LLM's Adoption dimension is normalised against other LLMs, not against the entire index.

Data sources

Every trust score is built from publicly available data. No private data. No paid data feeds. No provider self-reporting. Here are the sources Fabric uses, what we pull from them, and how often.

Source reliability

Not all sources are always available. When a source is temporarily unreachable (e.g. GitHub API rate limit), the sub-signal is marked as "no data" and its weight is redistributed to the other sub-signals in the same dimension. This prevents a temporary data collection failure from unfairly tanking a score.

Improving your score

Trust scores are fully automated. There is no manual review process, no paid placement, and no way to influence your score other than improving the underlying signals. Here's what actually moves the needle, ordered by impact.

Highest impact — Vulnerability & Safety (25% weight)

• Patch known CVEs promptly — unpatched critical vulnerabilities carry the steepest penalties (−2.0 per CVE) and can trigger automatic blocking
• Audit your dependency tree — transitive vulnerabilities (in your dependencies' dependencies) also count against your score
• Remove unnecessary dependencies to reduce attack surface and lower your dependency count sub-signal
• Add a SECURITY.md with a responsible disclosure process (boosts the Transparency dimension's security policy sub-signal)

High impact — Maintenance Activity (15% weight)

• Commit regularly — the commit recency sub-signal scores <7 days as 5.0 and drops steeply after 30 days
• Release regularly — a consistent release cadence is a strong positive signal
• Respond to issues promptly — <24h median response time scores 5.0
• Add CI/CD workflows — the CI/CD presence sub-signal gives 5.0 for GitHub Actions workflows vs. 2.0 without

Moderate impact — Operational Reliability (15% weight)

• Maintain strong uptime — ≥99.9% scores 5.0, measured over a rolling 30-day window
• Ensure your endpoint URL is reachable — services with a live, monitored endpoint score higher than registry-only listings
• Keep p99 latency consistent and under 500ms

Moderate impact — Adoption (15% weight)

• Grow real usage organically — the signal uses logarithmic tiers and is category-normalised
• Sustained growth in downloads is a positive signal; sustained decline is a negative one
• GitHub stars contribute — ≥5k stars scores 4.0, ≥10k scores 5.0

Moderate impact — Transparency (15% weight)

• Open source your code — permissive OSI licences (MIT, Apache) score highest at 5.0
• Write thorough documentation with code examples — README >2kb with docs site scores 5.0
• For AI models: publish a model card (+0.5 bonus)
• Add a CHANGELOG.md alongside GitHub releases for maximum score

Moderate impact — Publisher Trust (15% weight)

• Use an organisation account rather than a personal account (+0.5 bonus)
• Build a track record — account age and number of maintained repositories matter (≥5 years scores 5.0)
• Keep identity consistent across registries — presence on GitHub + npm + PyPI scores 5.0
• Grow your organisation's external credibility (followers, total stars across repos)

FAQ

Changelog

Notable changes to scoring methodology, data sources, and the Trust Index platform.

Legal

By using Fabric's Trust Index or any other part of the Service, you agree to the following. Full legal documents are linked below — this section summarises the key points relevant to users.

Trust scores are informational, not guarantees

Fabric trust scores are algorithmically generated from public third-party data sources. They are point-in-time assessments and may not reflect the current state of any indexed service. The scoring engine is in active beta — signals, sub-signal weights, and thresholds are being calibrated as coverage expands. Scores should not be your sole basis for any decision involving data security, financial transactions, or the selection of AI tools for business-critical applications. A "Trusted" score does not mean a service is safe — it means low risk was detected at the time of scoring.

No endorsement of third-party services

Fabric does not operate, control, endorse, or guarantee any third-party service indexed in the Trust Index. We aggregate and analyse data to generate scores. We do not audit, certify, or recommend any provider. Inclusion in the index is automatic and does not imply any relationship between Fabric and the indexed service.

Limitation of liability

To the maximum extent permitted by law, Fabric shall not be liable for any indirect, incidental, special, consequential, or punitive damages arising from your use of the Service, reliance on trust scores, or interactions with third-party services discovered through Fabric. Total aggregate liability is capped at the greater of fees paid in the preceding 12 months or USD $100.

Full legal documents