jnar — Journal of Negative & Applied Results

For labs & institutions

Reproducibility your whole lab can see.

Give your group one place where methods, replications, and fixes stay attributed and versioned — privately, with moderation and credit built in.

Tanaka Lab · membrane biology Private
RT R. Tanaka admin
AM A. Moreau author
KL K. Lindqvist reviewer
JP J. Park contributor
3 protocols · 11 contributions · 2 pending review

Private projects & moderation

Keep work-in-progress methods inside your group, with an internal review queue before anything is integrated.

  • Private, group-only protocols
  • Internal review & moderation queue
  • Approve or decline contributions

Team credit & onboarding

Every member keeps ORCID-attributed credit. New people inherit the lab's methods on day one — no re-typing tribal knowledge.

  • ORCID credit per member
  • Onboard with the lab's living methods
  • Roles & permissions

Access controls

Control who sees and edits what. Enterprise identity and residency are coming as institutions adopt jnar.

  • Granular project access
  • SSO / SAML roadmap
  • Data residency roadmap

Team sharing

Share protocols across the lab.

The usual way to share a lab protocol with the team is to email a Word file and hope everyone is on the same copy. Within a year that's six divergent versions and no one is sure which one works. On jnar each method is one canonical, versioned protocol your whole group works from — sharing it is pointing people at a single link, and any fix one person makes is immediately visible to all of them.

  • One canonical protocol per method — no v3_FINAL copies
  • Private to your group until you choose to publish
  • A fix one member makes is visible to the whole lab
Shared with · Tanaka Lab 1 canonical
RT R. Tanaka admin
AM A. Moreau author
KL K. Lindqvist reviewer
JP J. Park contributor
Everyone reads & proposes against the same version — no forwarded files

Version control

Version control your methods.

Every protocol on jnar is a versioned object. Each published change creates a new version with a precise, file-hash-aware diff and a recorded reason — so the lab keeps not just what the method is now, but how it got there and why. On a team workspace, version control stops being one person's discipline and becomes the group's: replications and fixes land as structured contributions through an internal review queue before anything is integrated.

It's the idea behind Git — version, diff, attributed history — adapted for wet-lab methods, with no command line. See how protocol version control works →

Knowledge management

Onboard new members on day one.

A lab's real knowledge isn't the protocol steps — it's why each step is the way it is: the buffer that fixed a transfer, the blocking agent that saved a phospho-signal, the antibody lot that ruined a week. Usually that lives in one person's head or notebook, and when they leave, it leaves with them.

jnar keeps that reasoning attached to the method as a versioned fix history, so it becomes the lab's institutional memory instead of tribal knowledge. A new member inherits the group's living methods — current versions and the failures behind them — on their first day, rather than re-learning them by breaking the same experiments.

  • Lab method documentation that updates itself with every version
  • Why a step changed is recorded next to the change
  • New hires inherit the living methods, not a stale SOP folder
Honest

Compliance and identity features — SSO/SAML, data residency, and formal compliance attestations — are on the roadmap, not shipped. We'll mark them as live only when they are. No fake institutional logos here, either: jnar is new, and we won't pretend otherwise.

Start a team, or just talk it through.

No hard sell. Tell us about your group and what you need, and we'll help you set it up — or point you to the free tier if that's all you need today.

Talk to us about a team workspace

Team workspaces are for groups with more than one member: private projects, internal moderation, roles, and ORCID team credit.

We'll only use your details to get back to you.

FAQ

Labs & institutions, answered.

Does jnar support SSO/SAML, data residency, or compliance attestations?

Not yet. SSO/SAML, data residency, and formal compliance attestations are on our roadmap, not shipped. We'll mark them as live only once they actually are — we won't imply institutional features we don't have.

Can my lab keep protocols private?

Yes. Team workspaces give you private, group-only projects with an internal review and moderation queue, so work-in-progress methods stay inside your group until you choose to publish.

How does credit work across a team?

Every member keeps ORCID-attributed credit. When an author integrates an accepted change, the contributor is named in the fix history and version diff — credit compounds across the whole group instead of disappearing.

How do we get started?

Team workspaces are for organizations with more than one member. Talk to us about your group and what you need and we'll help set it up — or point you to the free single-person tier if that's all you need today.

How do you share protocols in a lab?

Put each method on jnar as one canonical, versioned protocol and give your group a private team workspace. Everyone works from the same living version instead of emailing Word files around, so there's no "which copy is current?" — sharing a lab protocol with the team means pointing them at one link, and any fix one person makes is visible to all of them.

How does jnar help with lab knowledge management?

A lab's real knowledge isn't the protocol steps — it's why each step is the way it is: the buffer that fixed a transfer, the antibody lot that ruined a week. jnar keeps that reasoning attached to the method as a versioned fix history, so the institutional memory lives in the protocol instead of in one person's notebook. When someone leaves, their know-how stays with the lab.

Can jnar be our lab method documentation?

Yes. Each protocol is structured method documentation that stays current by design: every change is a new version with a precise diff and a recorded reason, attributed via ORCID. It's documentation that updates itself as the method improves, rather than a static SOP file that drifts out of date the moment someone tweaks the bench protocol.