Skip to main content
Building Silan Viking13 min read

Silan Viking — Make Research Work Findable

Silan Hu#ai-readable-research#make-research-work-findable#research-discoverability
Silan Viking — Make Research Work Findable cover

Make research work findable with a local-first workflow that keeps claims, evidence, project pages, researcher profiles, and AI/search metadata consistent.

Body

AI is now in the loop of research—from related-work discovery to paper understanding and peer review. Publishing a paper is no longer enough. Researchers need their work to be continuously discoverable, understandable, and verifiable by both people and AI. However, researchers still lack a dedicated workspace to consolidate their academic assets and continuously publish them as structured, AI-readable research knowledge.

Silan Viking is a local-first workspace that transforms every research update into a complete, structured, and evidence-backed academic presence—keeping your work consistent across papers, project pages, researcher profiles, AI/search metadata, and every public representation.

To make research work findable is not merely to put a PDF online or add keywords to a personal website. It is to make the current claim identifiable, the evidence reachable, the surrounding work understandable, the author's publication decision explicit, and the deployed version verifiable. A person should be able to find the work and understand what it contributes. A search or AI system should be able to retrieve a stable page, distinguish its claims from its context, and follow the evidence without guessing which representation is authoritative.

That is the concrete problem Silan Viking is designed around.

Figure 1

The five explicit state transitions from a fresh result to a reviewed public page

What does “make research work findable” actually mean?

Research findability has at least three layers:

Layer

Reader question

Required signal

Discoverable

Does a relevant page exist, and can I reach it?

Stable URL, descriptive title, summary, language metadata, sitemap, and links from related work

Understandable

What changed, why does it matter, and how does it relate to prior work?

Clear claim, bounded explanation, project context, terminology, and typed relationships

Verifiable

What evidence supports the claim, who approved it, and is this the current public version?

Evidence links, provenance, review state, publication state, and deployed-version checks

A page can succeed at one layer and fail at another. A crawler may request a URL that contains an unclear claim. A reader may understand a project page but have no path to the paper or evidence. A résumé may state the latest result while the project page still describes the previous one. “Online” is therefore not the same as “findable.”

This distinction matters more now because research discovery is no longer performed only by a person browsing a conference program or following citations manually. Search engines, scholarly indexes, retrieval systems, and AI assistants increasingly mediate the path between a question and a research artifact. These systems do not share one database or one interpretation of the author. They see pages, metadata, links, language variants, citations, PDFs, profiles, and partial snapshots. If those representations disagree, the researcher has published several competing answers to the same question.

Publishing a paper is a milestone, not the end of publication

A paper is the strongest artifact for a particular contribution, but it is not the only representation through which the work is discovered.

The same research result may appear as:

  • a paper that contains the complete method and evaluation;
  • a project page that explains the line of work;
  • a researcher profile that establishes authorship and expertise;
  • a résumé entry that compresses the contribution;
  • a repository that exposes implementation and reproducibility material;
  • an article that explains a result in accessible language;
  • structured metadata used by search engines and AI retrieval systems;
  • a later update that changes the scope, evidence, or current conclusion.

These are not copies of one paragraph. They have different readers and different jobs. The paper argues rigorously. The project page organizes. The profile attributes. The résumé compresses. The article explains. Metadata identifies. The repository enables inspection.

The failure begins when these surfaces are maintained independently. A paper is accepted on Friday, but the project page still says “under review.” The résumé has the new title, while search metadata retains an old summary. A public article explains the result, but no explicit relationship connects it to the project or evidence. An AI answer retrieves the most crawlable page rather than the most authoritative one.

The expensive part is not writing any single sentence. It is preserving one research judgment across every representation without erasing the distinctions between them.

The real unit is a research update, not a webpage

Silan Viking treats a research update as a durable content event. The update has an identity before it has a polished page. It can carry evidence, relations, language variants, review state, publication state, and delivery signals as it moves through the system.

I think this is the key abstraction: a research website should not be a collection of finished pages. It should be a projection of an evolving research record.

Consider a concrete use case. An experiment finishes on Friday. The researcher already knows:

  1. what changed;
  2. why it matters;
  3. which evidence supports the result;
  4. what the evidence does not establish;
  5. which earlier public statement is now stale.

In the usual workflow, this knowledge is distributed into a slide, a chat message, a draft paragraph, a repository issue, and perhaps a reminder to update the website later. The context is rich on Friday and expensive to reconstruct a month later.

The first system requirement is therefore not “generate a beautiful page.” It is “preserve the smallest honest claim while the context is still available.”

Figure 2

Drafting a research update by voice in the current quick editor

The Research Update Lifecycle

Silan Viking makes the lifecycle explicit:


Each transition answers a different question.

1. Capture: what must not be lost?

Capture the smallest durable object: one observation, decision, result, or change in confidence. It may be a single sentence.

For example:

A newly recovered archive changes our date for the first deployment from 2019 to 2017.

The sentence does not need a polished title, search description, cover image, or publication decision. It does need a stable identity, date, source location, and current epistemic boundary. Otherwise it will decay into an untraceable note.

Figure 3

Dated research notes kept on the current Moments timeline

2. Structure: what can be claimed publicly?

When the result is ready to explain, structure it as an article or project update. A useful research page should answer four questions:

  1. What is the new claim?
  2. Which earlier judgment does it change?
  3. Where is the evidence, and what are its limits?
  4. What should the reader inspect next?

The goal is not to fill a template. It is to turn an unstructured observation into a bounded explanation that another person can evaluate.

Figure 4

Editing the article while its source structure remains visible

3. Connect: where does this update belong?

A Moment, Article, Project, Paper, and résumé entry are different objects. Their relationship should be explicit rather than maintained through copy and paste.

Connections let the article explain the evidence, the project page locate the result in a longer program, the résumé compress the contribution, and a person or Agent recover the provenance between them. Stable identity matters because titles, routes, and language variants can change while the underlying relationship remains.

4. Review: who is responsible for the public claim?

Research publication contains judgments that should not be silently delegated. An Agent can retrieve related records, draft a summary, prepare another language, identify stale pages, or add a missing relationship. Its output should remain a proposal with an inspectable diff.

The researcher decides whether the proposed text preserves uncertainty, whether the evidence supports the language, and whether the update is safe to publish. Agent proposal authority is useful. Autonomous publication authority is not required.

5. Publish: which state is explicitly public?

Editing does not publish. Indexing does not publish. Translating does not publish. Accepting an Agent proposal does not deploy.

A research update moves through explicit states: private draft, reviewed source, published item, deployed representation. This separation prevents a convenient editing tool from becoming an accidental disclosure mechanism.

Figure 5

Managing articles and publication state in the current desktop workspace

6. Verify: did the reviewed version reach the web?

A successful build is not enough. The system should compare the reviewed local content version with the content version currently deployed. This converts “I think the site was updated” into an inspectable delivery fact.

The reader ultimately receives an ordinary public page. They should not need to know Silan Viking, Markdown, Git, MCP, or the deployment stack. The system does its job when the explanation is easier to reach and trust.

Figure 6

The public blog listing produced from reviewed content

7. Observe: where did findability fail?

Post-publication signals are diagnostic, not proof of understanding.

  • Delivery: did the current reviewed version reach the site?
  • Human attention: did readers enter the result page or stop at an index?
  • Machine reachability: did a search or AI crawler request the URL?
  • Navigation: can readers move from the explanation to the paper, evidence, project, and author?
  • Opening clarity: does the title and summary correctly state the page's purpose?

A crawler request proves that a URL was requested. It does not prove indexing, ranking, understanding, or citation. A page view does not prove that the evidence was read. These signals help locate the next problem; they do not complete the epistemic argument.

Figure 7

Human traffic, crawler requests, and deployed-version status in the current dashboard

One update should create several honest representations

A common content-system mistake is to demand one canonical paragraph and render it everywhere. That reduces duplication but destroys the pragmatic role of each surface.

Suppose a new benchmark result improves a model's measured performance.

The paper should explain the experimental setting, baselines, uncertainty, and threats to validity. The project page should explain how the result changes the research program. The researcher profile should attribute the work and connect it to the author's expertise. The résumé should compress the contribution without pretending that compression is the full evidence. Search metadata should identify the page accurately without overstating the conclusion.

Consistency does not mean identical wording. It means that every representation refers to the same underlying claim, evidence, authorship, and current state.

Silan Viking therefore preserves separate content objects and connects them through stable identity and typed relations. The durable asset is not a page template. It is the graph that explains where a public statement came from, which evidence supports it, and which representation is current.

What makes research knowledge AI-readable?

“AI-readable” should not be treated as a magic file format or a promise of citation. It is a set of concrete properties that reduce ambiguity for machines and people:

  • a stable canonical address for the public item;
  • a descriptive page title and summary;
  • explicit language information and localized variants;
  • structured data that identifies the item, author, and content type;
  • a clear distinction between claim, context, and evidence;
  • links to related papers, projects, repositories, and profiles;
  • consistent authorship and identity information;
  • visible publication state and updated content;
  • crawlable HTML, sitemap entries, and machine-readable site context;
  • a path from the public explanation back to its reviewed source and evidence.

No single signal guarantees retrieval. Together they make it less likely that a search or AI system must infer identity, authority, or relationships from disconnected fragments.

This is why keyword insertion alone is too weak. A page about “research discoverability” that does not link claims to evidence is easy to retrieve but hard to trust. A rigorous paper with no stable surrounding context is trustworthy but difficult for a broader audience to locate and interpret. The system needs both.

Why local-first matters

Research contains private notes, provisional conclusions, rejected language, unpublished evidence, and public claims. These states should not be collapsed into a cloud editor's latest document.

A local-first workspace keeps authored Markdown/TOML and media as the source of truth. Git provides review, provenance, comparison, rollback, and cross-machine transport. A rebuildable index supports retrieval without becoming the only copy of the research record. Public pages, APIs, sitemaps, structured metadata, and llms.txt remain derived outputs.

The architecture separates four authorities:

Authority

Responsibility

Authoring

Create and revise private or reviewed source

Proposal

Let an Agent prepare bounded, inspectable changes

Publication

Let the owner decide which item becomes public

Deployment

Project reviewed public content to the live site

This separation is not ceremony for its own sake. It prevents a tool that is useful for maintenance from gaining silent control over publication.

Findability is a system property, not an SEO checklist

Search optimization is useful when it helps a real reader reach a complete answer. Google Search's public guidance similarly emphasizes descriptive titles, useful summaries, accessible page content, clear authorship, first-hand expertise, and substantial people-first information rather than pages written primarily to manipulate rankings.

For Silan Viking, the operational checklist is:

  1. Identity: one stable URL and one clear page purpose.
  2. Relevance: the title, excerpt, H1, and opening directly answer the intended query.
  3. Depth: the page defines the problem, system abstraction, concrete workflow, tradeoffs, and current boundary.
  4. Evidence: claims lead to papers, projects, repositories, screenshots, or other inspectable artifacts.
  5. Relationships: related work links back to the same research graph.
  6. Language: English and Chinese variants remain explicit rather than mixed into one ambiguous page.
  7. Delivery: the reviewed content version is actually deployed.
  8. Observation: crawler and reader activity produce diagnostic signals for the next revision.

This article deliberately uses “make research work findable” as its title and organizing question because that is the user problem it answers. It does not repeat the phrase as a substitute for substance.

What Silan Viking supports today

Today, Silan Viking can:

  • create and validate plain-text research content;
  • maintain articles, projects, moments, series, media, language variants, and résumé evidence;
  • connect related records through stable silan:// identities;
  • keep private/public state explicit;
  • build a rebuildable local index;
  • preview and deploy to an explicitly configured site;
  • produce stable public routes, summaries, structured data, sitemap, robots rules, and llms.txt;
  • compare local and deployed content versions;
  • separate human activity from heuristically classified search and AI crawler requests;
  • let Agents retrieve context and prepare reviewable proposals through MCP.

The released CLI and the current source tree do not have the same packaging boundary. The desktop workbench currently runs from a full source checkout; packaged desktop onboarding and direct cross-device continuation remain in progress. Git is the current cross-machine source path.

These details matter because a research tool should not market planned capabilities as deployed facts. Verifiability begins with the product's own claims.

Start with the result you are already postponing

Do not migrate an entire career. Start with one result that exists in a slide deck, chat, notebook, or stale project page.

Create a private research update:


Then write four things:

  • what changed;
  • why it matters;
  • what evidence supports it;
  • what remains uncertain.

The first success is not “the entire academic website is automated.” It is one valid private page whose identity, evidence, relationships, and publication decision remain under the researcher's control.

Take that update through review, publication, deployment, and verification. If the paper, project page, researcher profile, and search metadata can all remain honest without rebuilding the website around each new result, the research presence has become maintainable.

Make research work findable by preserving its structure

The web does not need another disconnected summary of a paper. Researchers need a durable way to preserve the structure around their work: the current claim, supporting evidence, related artifacts, author identity, review decision, publication state, and deployed version.

Silan Viking turns that structure into a local-first research workspace and a public, machine-readable academic presence. The website is one projection. The deeper system is the record that keeps every projection connected.

That is what Make Research Work Findable means: not a promise that every system will rank or cite the work, but an infrastructure commitment that people and machines can discover the right page, understand the current contribution, and verify where the claim came from.

0 likes
Silan Hu52 readsShare:

No comments yet