Cara Menghubungkan Evidence ke Entity tanpa Membuat Graph Palsu

✦ GEO.OR.ID KNOWLEDGE SYSTEM

Cara Menghubungkan Evidence ke Entity tanpa Membuat Graph Palsu

◆ FormatPost
↻ Diperbarui18 October 2026
◷ Waktu baca9 menit
✦ KonteksPanduan praktis

Ada godaan besar saat membangun knowledge graph untuk brand.

Kita punya entity Organization.

Kita punya artikel media.

Ada case study.

Ada testimonial.

Ada sertifikasi.

Ada partner page.

Ada award.

Lalu semua ditarik garis ke Organization.

Kelihatannya kuat.

Masalahnya, garis tidak otomatis berarti evidence benar-benar mendukung seluruh entity atau seluruh claim tentang entity tersebut.

Satu artikel media bisa membahas founder, bukan company performance.

Satu award bisa diberikan untuk product tertentu, bukan seluruh organization.

Satu certification bisa berlaku hanya untuk lokasi, scope, atau periode tertentu.

Satu case study bisa membuktikan satu project, bukan kemampuan universal.

Kalau semuanya ditempel ke entity dengan relationship generik seperti `supportedBy`, graph terlihat kaya tetapi semantics-nya palsu.

Evidence graph yang sehat harus menjawab dua pertanyaan:

Evidence ini membuktikan apa?

Dan untuk entity mana, dalam scope apa, pada periode apa?

Kalau dua pertanyaan itu tidak dijawab, knowledge graph berisiko berubah menjadi dekorasi trust.

Entity Bukan Claim

Ini distinction paling penting.

Organization adalah entity.

“Organization ini memiliki sertifikasi X” adalah claim.

“Organization ini meningkatkan revenue client Y sebesar Z” adalah claim.

“Organization ini didirikan tahun 2020” adalah claim.

Evidence mendukung claim.

Bukan “mendukung entity” dalam arti umum.

Jadi model yang lebih jujur:

Organization A
→ hasClaim
→ Claim B

Claim B
→ supportedBy
→ Evidence C

Sekarang relation punya meaning.

Example:

Organization:
PT Nusa Data.

Claim:
“PT Nusa Data memiliki sertifikasi ISO tertentu.”

Evidence:
Certificate page / public registry / certification document.

Much cleaner.

Kalau certificate expired, claim status bisa diubah.

Entity tetap ada.

Graph tidak perlu dibongkar total.

Skenario yang Sering Terjadi

Marketing:
“Kita punya artikel media besar. Link-kan ke Organization sebagai authority evidence.”

Editor:
“Artikel itu cuma wawancara founder.”

Marketing:
“Tapi brand disebut.”

Legal:
“Apakah artikel itu membuktikan company claim apa?”

Hening.

Exactly.

Media mention bisa menjadi evidence bahwa:

Founder memberi statement.

Company announced product.

Event happened.

Brand existed in market at date.

It does not automatically prove:

Company terbaik.

Company terpercaya.

Company market leader.

All services validated.

Evidence harus claim-specific.

Generic Trust Edge adalah Red Flag

Relationship seperti:

trustedBy.

authoritativeBecause.

verifiedBy.

provenBy.

sering tempting.

Tetapi apa definisinya?

“Media X proves Organization A.”

Proves what?

Existence?

Reputation?

Performance?

Ownership?

Location?

If relation cannot be translated into precise sentence, avoid.

Internal graph may have custom trust score, but public representation should be cautious.

Trust is multidimensional.

Don't convert every mention into authority edge.

Evidence Type Harus Diklasifikasikan

Useful taxonomy:

Identity evidence:
Proves who entity is.

Example:
Official registry, corporate page, verified profile.

Relationship evidence:
Supports relation between entities.

Example:
Founder announcement, acquisition filing, partner page.

Capability evidence:
Supports product/service capability.

Example:
Technical docs, certification, case study.

Outcome evidence:
Supports result claim.

Example:
Measured case study, public report.

Reputation evidence:
Third-party review, award, analyst coverage.

Compliance evidence:
License, certification, regulator listing.

Temporal evidence:
Announcement showing change date.

Each type has scope.

Do not use reputation evidence to prove legal identity.

Do not use identity evidence to prove performance.

Claim-to-evidence alignment matters.

Case Study Bukan Bukti Universal

Case study:
Client A improved metric B after project C.

It supports:

Project occurred.

Approach used.

Observed outcome under described conditions.

It does not automatically support:

Same outcome for all clients.

Service always works.

Organization is best in market.

Method causes result with certainty.

Good graph stores:

CaseStudy → about → Project.

Project → deliveredBy → Organization.

Project → forClient → Client if public/consented.

Claim → observedIn → CaseStudy.

Now semantics bounded.

No fake universal edge.

Testimonials Perlu Status

Testimonial may be:

Named.

Anonymous.

Verified.

Unverified.

Current.

Historical.

Paid/sponsored.

Collected by platform.

Internal.

Public.

Graph should distinguish.

A testimonial is evidence of someone's statement.

Not necessarily objective proof of result.

Model:

Person/Organization X
→ said
→ Testimonial statement

Statement
→ about
→ Organization Y

Source:
testimonial page.

If you turn testimonial directly into “Organization Y is excellent”, graph converts opinion into fact.

Avoid.

Award Evidence juga Scope-Specific

Award:
“Best Product Design 2025” for Product A.

Don't connect:

Organization → award-winning → all services.

Better:

Product A → receivedAward → Award X.

Organization → owns/produces → Product A.

Now reader can infer context naturally.

If award explicitly given to organization, model that.

Precision preserves credibility.

Certification Harus Punya Scope dan Validity

Certification is one of the easiest places to overclaim.

Certificate may apply to:

Specific legal entity.

Specific facility.

Specific process.

Specific product.

Specific timeframe.

Example:
ISO certification for quality management system of PT A, valid until date.

Do not write:

Brand B is ISO certified.

unless Brand B relationship and scope make statement accurate.

Graph:

Certificate → issuedTo → Organization.

Certificate → scope → specific operation.

validFrom/validThrough.

issuer.

source.

This supports audit.

Expired certificate remains history but should not be treated current.

Partner Logo Bukan Selalu Evidence Partnership

Website shows logo of Company X.

Does that mean official partnership?

Could mean:

Client.

Technology used.

Marketplace integration.

Customer.

Media mention.

Sponsor.

Distributor.

Partner.

Logo alone ambiguous.

Do not create Partner edge without source text.

Need explicit relationship.

“Official technology partner.”

“Authorized reseller.”

“Integration partner.”

“Client.”

Different predicates.

Graph falsehood often starts from logo interpretation.

External Mentions Bisa Jadi Evidence of Existence, Bukan Quality

A news article mentioning company confirms:

Company was discussed.

Possibly event, product, person.

It doesn't automatically validate all claims.

Marketing teams love media because independent source feels strong.

Use it, but accurately.

Claim:
“Company launched Product X in May.”

Article supports.

Claim:
“Company is market leader.”

Article must explicitly support or cite data.

Do not infer from publication brand prestige.

Evidence Graph Harus Punya Provenance

For every evidence edge:

Source URL.

Publisher.

Date.

Author if relevant.

Accessed date.

Evidence type.

Claim supported.

Scope.

Reviewer.

Status.

Confidence if internal.

Example:

EV-2031
Type: regulatory listing.
Claim: Organization A licensed for service B.
Source: regulator URL.
Effective date: …
Verified: …
Status: current.

Now audit possible.

Screenshot alone not enough.

Source may change.

Store citation metadata.

Evidence Bisa Menjadi Konflik

Source A:
Founder = Person X.

Source B:
Founder = Person Y.

Don't connect both as true silently.

Graph can model:

Claim 1 supported by Source A.

Claim 2 supported by Source B.

Conflict status.

Human review.

Maybe co-founders.

Maybe Source A wrong.

Maybe name changed.

Evidence graph should expose contradiction internally.

Public graph should not publish unresolved conflict as certainty.

This is why claim layer is valuable.

It prevents source ingestion from directly mutating entity truth.

Automation Tanpa Claim Layer Berbahaya

Imagine pipeline:

Crawl web.

Extract Organization relation.

Add graph edge.

Publish schema.

Fast.

Scary.

Better:

Crawl.

Extract proposed claim.

Attach evidence.

Confidence score.

Entity resolution.

Rule validation.

Human review for high-risk.

Approve.

Update canonical graph.

Publish public projection if appropriate.

Automation can scale discovery.

Human governance controls truth.

AI-generated graph should never automatically become public fact for critical entities.

Evidence Quality Score Boleh Ada, tetapi Jangan Jadi Kebenaran Publik

Internal score:

Source authority.

Recency.

Directness.

Independence.

Specificity.

Corroboration.

Useful.

But weights are organizational choices.

Don't publish:

“Evidence score 92 = fact true.”

No.

Scores help triage.

Fact verification still requires context.

A regulator source may outweigh many blogs.

Ten scraped directories repeating one wrong source are not ten independent corroborations.

Deduplicate source lineage.

Source Independence Penting

Media A and B both copy press release.

Looks like two independent sources.

Actually one origin.

Evidence graph can store:

derivedFrom.

syndicatedFrom.

quotes.

This prevents false corroboration.

For high-stakes claims, trace to primary.

Example:

“Company raised $10M.”

20 articles repeat.

Primary:
Company announcement or filing.

Graph should know.

Otherwise count inflation creates fake confidence.

Evidence Freshness Harus Dipantau

Claim:
CEO is A.

Evidence:
2024 profile.

Current 2026?

Maybe stale.

Evidence has date.

For dynamic facts, old evidence weight should decline operationally.

Not because old source “bad”.

Because claim changes.

Set decay policy.

Leadership:
review frequently.

Founding date:
stable.

Product availability:
dynamic.

Legal ownership:
event-driven.

Certification:
expiry-driven.

Evidence governance depends on fact lifecycle.

Public Evidence Page Bisa Menjadi Useful

For trust-heavy organization, create evidence hub.

Not marketing wall.

Structure:

Claim.

Evidence.

Method.

Date.

Limitations.

Source.

Example:

“Observed result: X.”

Method:
How measured.

Period.

Scope.

Limitation.

Link to case study.

This helps human buyer and machine retrieval.

But don't make 100 pages each claiming universal proof.

Evidence hub should be auditable.

Less hype.

More specifics.

Knowledge Graph Internal Bisa Lebih Detail daripada Public

Internal graph:

Claim IDs.

Evidence IDs.

Confidence.

Reviewer.

Conflict.

Source lineage.

Public site may only show:

Case study.

Certification.

Research.

Source links.

You don't need expose internal confidence matrix.

Graph infrastructure can support editorial truth without dumping metadata publicly.

This avoids turning website into machine database.

Evidence Harus Bisa Dicabut

What if:

Client withdraws permission.

Certificate expires.

Partner ends relationship.

Study corrected.

Article deleted.

Claim disproven.

Graph needs lifecycle.

status:
active.

expired.

withdrawn.

superseded.

disputed.

archived.

Do not delete history blindly.

But public projection should not treat inactive evidence as current.

This is trust hygiene.

Link Rot Harus Ditangani

Evidence URL 404.

Now graph edge points nowhere.

Monitor.

If source moved, update.

If archived, use official archived source if permitted.

If no longer available, mark.

Don't replace with random mirror just to keep edge alive.

Provenance matters.

A dead evidence link weakens auditability.

Entity-Evidence Mapping untuk AI Observation

After cleaning evidence graph, test.

Does AI cite:

Official evidence page?

Third-party evidence?

Unrelated page?

Does recommendation use unsupported claims?

Does entity accuracy improve?

Do not promise causation.

Graph correctness is first objective.

AI citation is downstream.

Measurement separate.

If source selection changes after evidence architecture, report association.

Not proof that “graph caused citation”.

Avoid Fake Graph Through Reciprocal Linking

Another temptation:

Every entity page links to every evidence page.

Every evidence page links back.

Then call it knowledge graph.

That's just dense internal linking.

Could be useful if contextual.

Could be spam if forced.

Graph relation should be semantic.

Link only when reader benefits.

Evidence page naturally identifies entity.

Entity page may link to key evidence.

No need 50 reciprocal links.

Relationship exists in data governance even if not every edge appears as hyperlink.

Audit Checklist

For each evidence link:

What claim does it support?

Which entity?

What type of evidence?

Primary or secondary?

Independent?

Current?

Scope?

Source URL?

Date?

Reviewer?

Conflict?

Public?

Can it be revoked?

Does page text accurately describe evidence?

If one question unanswered, edge may need review.

Evidence Bukan Dekorasi Authority

Good evidence architecture feels conservative.

Claims narrow.

Sources clear.

Dates visible.

Limitations present.

Relationships specific.

Bad architecture feels like:

Brand → trustedBy → everyone.

Brand → featuredIn → all media.

Brand → awardWinning → generic.

Brand → certified → unspecified.

Looks powerful.

Actually unverifiable.

In AI-era search, fake certainty is especially dangerous because machines can amplify it.

The safer strategy is boring:

Say exactly what is supported.

No more.

No less.

Relationship graph then becomes useful because humans can inspect every edge and say:

“Yes, this evidence supports this claim about this entity under this scope.”

That is a real graph.

Everything else is lines on a slide.

Leave a Comment

Your email address will not be published. Required fields are marked *