Vauntico previously used a composite TrustScore to summarize public engineering signals. The product has since moved toward an evidence-first public snapshot because a single score can hide the source, scope, uncertainty, and missing information behind the number.
The change is not a claim that every summary metric is inherently wrong. It is a more specific lesson about public evidence: an observed signal, an unavailable signal, and a private system are not interchangeable. If a public score makes those differences hard to see, it can imply more certainty and completeness than the observations justify.
The current question is therefore not only, “What score did this founder get?” It is:
What was observed, where did it come from, what does it support, and what remains unknown?
What changed
TrustScore was an earlier Vauntico product model. It offered a compact summary of signals that could be useful as a starting point, but the summary could be read as a broader judgment than the underlying public observations supported.
The current public experience makes the evidence itself primary. Each observation should be read with its source, scope, collection time, and limitation. A reader can then decide what question the observation may help investigate and what additional evidence is needed.
This is product-model refinement based on stricter evidence discipline, not a reason to shame the earlier model. Old screenshots, references, indexed pages, or historical discussions may still mention TrustScore because that was the language used at the time.
Why a composite score can overstate certainty
A composite score can collapse several different realities into one output:
- evidence that was actually visible in a public source;
- information that was not visible publicly;
- information that was private;
- information that was not checked;
- information that cannot be inferred from GitHub;
- signals with different freshness; and
- signals covering different scopes.
The dangerous shortcut is:
not observed → negative
That inference is not always valid. No visible public CI configuration does not prove that no CI exists. No public incident history does not establish incident response quality. A public profile does not establish production-access controls, and an absent public security artifact does not prove that the underlying process does not exist.
The opposite mistake is also possible: treating an observed public signal as proof of a private or company-wide reality. Evidence discipline requires keeping both errors visible.
The current public GitHub snapshot
The current public snapshot is:
- public GitHub only;
- point-in-time;
- based on observable public information;
- evidence and context, not a comprehensive engineering-quality judgment; and
- inspectable, with source context and limits.
The current snapshot methodology describes four evaluator evidence areas:
Account tenure
The public GitHub account creation date shows how long the public profile has existed. It does not establish engineering quality, identity beyond the public profile, or the state of private work.
Public repository footprint
The snapshot can count public repositories visible at scan time. Private repositories and their contents are not included.
Recent public activity
The snapshot can summarize matching public commit activity observed across accessible repositories during the available 30-day window. It does not measure private work or code quality.
Public profile fields
The snapshot can show whether selected public profile fields, such as bio, company, location, and website, are present. Field presence does not verify the claims contained in those fields.
The free public GitHub snapshot reports these bounded observations with source and observation-window context. The current public experience does not turn them into a composite TrustScore, a rating of the company, or a conclusion about a founder as a person.
What the public snapshot cannot prove
Public GitHub evidence does not establish:
- private repository contents or private repository controls;
- production infrastructure, production access, or private deployment configuration;
- company-wide MFA;
- incident-response performance or internal policies;
- private vulnerability state or private dependency posture;
- customer-data handling;
- contractual compliance, certification, or SOC 2 compliance;
- buyer approval;
- engineering ability as a whole;
- founder trustworthiness as a person; or
- universal operational maturity.
These are not reasons to dismiss public evidence. They are reasons to describe it at the scope it actually covers. The scan's scope is public GitHub evidence only, not an assessment of engineering quality, the engineering team, or the company as a whole.
Observed, negative, missing, and out of scope are different
Observed evidence
Something was actually visible and attributable within the checked public scope. For example, a public repository count or a public commit-search result may be observed at scan time.
Negative evidence
There is valid evidence supporting a negative conclusion within an appropriate scope. A missing public signal is not automatically this state.
Missing or unavailable evidence
The current public source cannot show or verify the information. Private repositories, internal policies, and production access are examples of information that may be unavailable to a public GitHub snapshot.
Not checked or out of scope
The question cannot be answered from this public snapshot at all, or the relevant system was not part of the checked source. That is a boundary, not a negative finding.
Keeping these states separate is why the current public artifact shows what was observed and what it could not observe. It does not convert uncertainty into a score.
Evidence first; score second
A summary metric can be useful only when a reviewer can inspect what contributed to it, which source supplied each input, what scope was checked, and what was not observed. Even then, the metric remains a summary rather than a replacement for the underlying evidence.
For the current public product, the evidence is primary. The public methodology explains the four evaluator areas and their limits, while the scan presents the public observations available at collection time. The current public snapshot does not restore the old composite score or score-derived tiers.
Why this matters to a founder
If you share public engineering evidence with a reviewer, you should be able to say:
- what was observable;
- which public source supplied it;
- when and within what scope it was observed;
- what the observation may help a reviewer investigate; and
- what would require private evidence or a different review.
That is more defensible than asking a buyer to treat a black-box composite score as a complete description of your engineering practice. It also gives the buyer a clearer next question without pretending that public evidence settles it.
Public snapshot question versus buyer diligence question
These are different questions:
Public snapshot question: What can be observed publicly at scan time?
Buyer diligence question: What evidence supports this specific buyer claim?
For example, a buyer asking, “Do you enforce MFA for all production access?” is asking about MFA, production scope, identities, and access paths. A strong public GitHub profile cannot answer that question by itself. The appropriate evidence may be private identity-provider configuration, an access review, or another source the buyer accepts.
If the buyer's wording is unclear, Questionnaire Evidence Triage can help interpret what the buyer appears to be asking and suggest relevant evidence categories. It does not inspect private systems, verify the company's evidence, infer private controls, answer on the founder's behalf, or guarantee buyer acceptance.
A practical way to share the snapshot
When sharing a public result, describe it in four parts:
- Here is what the public source showed.
- Here is the source, collection time, and scope.
- Here is what the observation may help you investigate.
- Here is what remains unknown and where private evidence is required.
That wording lets a reviewer use the snapshot without confusing public context with a complete security, diligence, or company assessment.
The short version
TrustScore was part of Vauntico's earlier product history. The current public direction is more explicit: show bounded public GitHub observations, preserve their source and limitations, and leave missing or private information visibly unknown.
The value is not a number that claims to settle trust. It is an inspectable starting point for the next question.