Silan Viking — Make Research Work Findable

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.

Why accepted research can still be hard to find

Imagine an experiment finishes on Friday. You already know what changed, why it matters, which evidence supports the result, and what the evidence does not prove. The expensive part is no longer forming the judgment. It is carrying that judgment across a paper, lab note, project page, résumé, repository, image, language variant, structured metadata, and deployment without changing its meaning.

The conventional publishing model treats the paper as the terminal artifact. That model becomes incomplete when a person or an AI system tries to answer narrower questions:

• What problem does this work actually solve?
• Which artifact is the canonical implementation?
• Is the result active, superseded, or only an early idea?
• Which claims are supported by a paper, benchmark, dataset, demo, or code release?
• How is this project related to the researcher's other work?
• Has the public explanation changed since the version that was originally indexed?

A PDF can contain the answer and still be difficult to discover. A project page can rank for a title and still fail to expose the evidence behind its claims. A researcher profile can list a publication and still omit the technical context needed by a related-work agent. The problem is not merely academic SEO. It is the absence of a maintained public research model.

What “make research work findable” means

To make research work findable, a system has to preserve four properties at the same time.

Discoverable

Every public result needs a stable URL, a useful title and summary, explicit relationships, crawlable HTML, sitemap coverage, language alternates, and machine-readable metadata. Search engines and AI crawlers should not need to reconstruct the identity of a project from disconnected pages.

Understandable

Finding a URL is not the same as understanding the work. A public representation should explain the research question, contribution, evidence, limitations, current state, and relationship to earlier or later results. The representation must serve a reader who has not seen the author's private notes or full paper.

Verifiable

Claims should remain connected to evidence and release provenance. The public site should be able to report which committed content revision is live, which code artifact rendered it, and whether the media and static release correspond to that revision.

Maintainable

Research changes after publication. A new experiment may narrow a claim; a camera-ready paper may replace a preprint; a repository may move; a project may become part of a broader system. Findability therefore has to be a continuous workflow, not a one-time launch checklist.

Silan Viking treats these properties as one publishing lifecycle:

One research update, several public representations

Silan Viking does not merge every academic asset into one large document. A paper, project page, researcher profile, dated update, and machine-readable index serve different readers. Instead, each record receives a stable identity and explicit relationships.

For the Friday result, the workflow is concrete:

1. Capture the first useful sentence as a dated research moment while the reasoning is fresh.
2. Create a private article or project update that states the result, evidence, and uncertainty.
3. Link the update to the relevant project, publication, episode, moment, or résumé evidence.
4. Review the rendered public form and inspect any Agent-proposed changes before they enter the authored source.
5. Commit the reviewed revision so its identity and provenance are immutable.
6. Project the authored records into the local read model.
7. Publish a versioned content bundle through the production control plane.
8. Verify the deployed content commit, media generation, static release, and public route.

The article can explain the technical reasoning. The project page can organize the evolving body of work. The résumé can compress the contribution. Search metadata can expose stable identifiers and relationships. These views remain distinct, but they no longer drift independently.

Structured research knowledge instead of duplicated website copy

The source of truth is an ordinary local workspace: Markdown for prose, typed metadata for identity and lifecycle state, explicit relations between records, and versioned media beside the work it supports. A derived SQLite projection makes the content queryable without turning the database into the authoring authority.

This separation matters. Editing a production database directly makes the public page easy to change but difficult to reproduce. Generating a website directly from unstructured folders preserves files but loses semantic relationships. Silan Viking keeps the authored source local and reviewable, then builds disposable projections for the API, search, AI retrieval, and static site.

Draft and private records remain useful locally but are unreachable from the public projector. Publication authority stays with the researcher. An Agent may retrieve context or propose an edit; it does not silently make a claim public or deploy a production release.

Local-first is a research integrity boundary

“Local-first” here is not simply an offline feature. It defines ownership.

• The researcher owns the canonical files and their Git history.
• The public database is a derived read model, not the only surviving copy.
• Publication begins from a clean, committed research revision.
• Private and Agent namespaces are separated from public resources.
• Production receives a bounded bundle rather than access to the entire working directory.
• A release can be checked against the exact content commit that created it.

This boundary reduces an important form of uncertainty: whether the public claim is the same claim the researcher reviewed. It also keeps migration practical because the durable assets remain ordinary files rather than records trapped inside a hosted CMS.

Built for people, search engines, and AI research tools

Human-readable and AI-readable publishing are not separate content strategies. They are projections of the same reviewed research state.

For people, Silan Viking produces navigable project and article pages with stable routes, readable explanations, language variants, related work, and visible evidence boundaries.

For search engines, the frontend projection owns canonical metadata, localized routes, sitemap entries, robots policy, and structured public pages. Content updates prerender against the already compiled frontend code baseline, so changing a research claim does not rebuild unrelated application code.

For AI systems, public research context is available through crawlable HTML, llms.txt, about.txt, JSON-LD, stable links, summaries, and explicit relations. Locally, MCP provides bounded retrieval and reviewable proposal workflows over the richer private workspace.

Crawler activity is only diagnostic evidence that a URL was requested. It does not prove that a search engine or AI system indexed, understood, ranked, or cited the page. Silan Viking keeps that distinction explicit instead of converting traffic into an unsupported discoverability claim.

A release architecture for continuous research publishing

The production path is designed around one content-release state machine:

The CLI and Desktop use the same Rust application control plane. Content is synchronized into a derived SQLite projection, stamped with the full content commit, bundled with only the media required by the target generation, and sent to an authenticated Go deployment endpoint.

The server validates the bundle and schema version, transactionally promotes the content projection into PostgreSQL, switches the media generation, invokes the static publisher, and returns success only after the new static release is live and verified. Normal content publishing does not use SSH, does not download the live database, and does not recompile TypeScript or Vite assets.

Code deployment and content publication are separate operations:

Each static release includes provenance for the content commit, content hash, schema version, project code commit, frontend artifact digest, and generation time. This does not make every research claim automatically true; it makes the path from reviewed source to public representation inspectable.

Current capabilities and release boundary

The public v1.0 macOS/Linux CLI initializes and validates a workspace with articles, projects, episodes, résumé records, relations, proposals, site tooling, statistics, and MCP. The current main branch adds the Moment model, a Tauri/React desktop workbench, guided onboarding, dictation, richer review workflows, and the current silan.tech delivery architecture.

The working system includes:

• Typed research records with explicit private, unlisted, public, active, and archived states.
• Articles, projects, episodes, moments, résumé evidence, translations, relations, and media.
• Local schema validation, content linting, query projection, and drift checks.
• Stable public routes, structured metadata, sitemap, robots rules, llms.txt, and crawler-readable HTML.
• Reviewable Agent proposals through MCP, with owner-controlled acceptance and publication.
• Local/deployed revision checks, comments, human activity, and heuristic search/AI crawler classification.
• An authenticated content bundle transaction with media reconciliation and static-release verification.
• A local Docker preview path isolated from production code and content delivery.

The Moment/Desktop/onboarding work has not yet shipped in a post-v1.0 public release. A new workspace starts with the public CLI and ordinary files; the desktop workbench currently runs from a full source checkout.

Start with one postponed result

Do not migrate an entire academic career. Take one result that should have had a clear public explanation but never received one.

Write five things: the problem, what changed, why it matters, what evidence supports it, and what remains uncertain. Connect it to the relevant project or publication. Review the public form. Then decide whether the result is now easier to discover, understand, verify, and keep accurate than it was in the old workflow.

Frequently asked questions

How do I make my research work findable?

Start by giving each public result a stable identity and URL, then publish a concise explanation of the problem, contribution, evidence, limitations, artifacts, and relationships. Add crawlable HTML and structured metadata, but keep them derived from the same reviewed source so the paper, project page, profile, and search representation do not drift.

Is research discoverability the same as academic SEO?

Academic SEO is one part of discoverability. Titles, summaries, canonical URLs, sitemaps, language metadata, and structured data help systems locate a page. Research discoverability also requires enough context to understand the work and enough provenance to verify which evidence and revision the page represents.

Why is a paper or GitHub repository not enough?

A paper is optimized for scholarly evaluation and a repository is optimized for implementation. Neither automatically provides a maintained public map across claims, evidence, project status, researcher identity, related outputs, language variants, and machine-readable search context. Silan Viking connects these representations without replacing their distinct roles.

Can AI publish research changes automatically?

AI can retrieve context, draft material, identify missing links, and propose edits. In Silan Viking, accepting a claim, changing public visibility, committing the authored revision, and deploying production remain explicit owner actions.

Does an AI crawler request mean the work was indexed or cited?

No. A request proves only that a classified client accessed a URL. Indexing, ranking, understanding, use in an answer, and citation are separate outcomes and need separate evidence.

Make research work continuously findable

The practical shift is from “publish a paper” to “maintain a verifiable public research state.” Silan Viking turns that state into a local, reviewable workspace and continuously derives the public forms that people, search engines, and AI systems can inspect.

That is what make research work findable means here: not repeating a keyword across disconnected pages, but preserving one committed body of research knowledge as discoverable, understandable, verifiable, and continuously maintainable public representations.