This site is being rebuilt and some pages are out of date. For current details, write to reach@inorbit.hr. This notice goes away when the rebuild is done.

No analytics unless you allow it, no tracking. This site keeps in your browser the language you pick, the theme, its colour, which site you chose, the currency on the pricing page and that you closed this notice; signing in adds session cookies. The legal page has the details.

Sign in

← Back to Platform

RFC 0057open2026-10-05

One door, a person or a company, partners and a welcome

The site becomes two sites behind one door. A first visit shows what the platform does today and asks whether the visitor wants Nevio, the engineer, or InOrbit, the company. A company asks for access after signing up; the owner approves, the visitor signs the NDA and becomes a `partner`. The console welcomes a new person with a few questions and sets up a personal or a team template from the answers.

Problem

The site is one person's site with a company folded into it. The home page greets a visitor as Nevio, offers his availability, and lists the company's products in the same column. A visitor who came for the platform has to read past a CV to find it, and a visitor who came to hire an engineer has to read past products.

A company that wants to try the platform has no way to ask. Sign-up is open, but a new account sees its keys, its usage and its team, and nothing that the platform does. The products are admin-only until they are opened, so a prospective partner either becomes an admin, which gives them every admin action, or sees nothing.

The console does not know who just arrived. A person signing in for the first time is told "Welcome back" and left on an overview that assumes they have already set things up. Setting up the platform is nine separate pages in an order only the docs explain.

Proposal

The door

A first visit to the site opens on a full-screen page in front of the home page. It shows what the platform does today, drawn the way the site already draws things:

  • the loop the platform is built around (understand, observe, model, hypothesize, experiment, change, verify, grade, evidence), each step linked to a real public piece of work: a published RFC, the latest Radar change, an open-source tool;
  • a terminal that types real iohr commands and shows their real output.

Nothing on the door describes a capability that is not built.

Then one question with two equal answers:

  • Nevio, to work with an engineer. It opens the site as it is today, unchanged.
  • InOrbit, the company and the platform. It opens the company home.

The answer is kept as a preference shared with the console, the same way the theme and the language are, and a switch in the header changes it later. A returning visitor goes straight to the site they chose. The door works from the keyboard (1, 2, Esc for the person), honours reduced motion, comes in English and Croatian, and loads after the home page so it never slows the first paint.

The company home

The company home starts as an exact copy of today's home page: the same sections in the same layout. Only the opening is rewritten for InOrbit, around the platform's thesis and what runs today. The other pages (the RFCs product, Radar, pricing, the lab) are shared by both sites until the company version of one is needed.

The company home answers each reader in turn:

  • Signed out: Request access, which goes through sign-up and comes back to the request.
  • Signed in without access: Request access.
  • A partner or an admin: Open the console.

Partners

A new platform role, partner, sits beside preview from RFC 0056. It opens what preview opens (the lab, the RFCs product and training, read-only), plus the console's products for the partner's own account: reliability, connections and the developer tools. It opens nothing of the operator's: no admin area, no other account's data, no admin call. Every other gate stays as it is: default deny. Opening a console product to partner means naming the role at the edge and in the service behind it, one product at a time, and each opening is recorded in this RFC's status log.

Nobody gives partner by hand.

Asking for access

A signed-in person asks for access with a short form: their company and, in at most 500 characters, what they want to do. A person has one open request at a time and can see its state.

The owner sees the requests in the console and approves or refuses each one. Approving does three things at once:

  1. it sends the NDA from RFC 0056, as an invitation that gives partner instead of preview;
  2. the mail invites the person to a conversation with the owner;
  3. signing the NDA makes them a partner, at once, with the same rule as RFC 0056: only a person who holds no other role is given it, and revoking the signature ends it.

Refusing sends a short note. Both are recorded with who decided and when.

A diagram is drawn here in the RFCs product; this page does not show diagrams yet.

The welcome

A person signing in to the console for the first time is welcomed and asked a few questions, each a choice:

  1. Personal or team. It starts from the door's answer when there is one.
  2. What first: watch a service, write RFCs with a team, learn with Radar and training, or connect tools.
  3. Where it runs: or a laptop, and the main language.
  4. For a team: its name and the addresses to invite.

The answers pick a template. The personal template is:

  1. sign in to the command line;
  2. make a key with the right scopes;
  3. verify a domain;
  4. enroll an agent;
  5. a starter checks file written from the answers;
  6. the first monitor.

The team template first makes the team, invites its members and sets its security policy (MFA, allowed domains), then runs the same steps for the team's account. Every command comes filled in with the person's own values and the current versions of the tools. A step the person's role cannot open yet says so and links to the access request.

Before the template, the welcome makes the first connection in place: an API token with the scopes the first goal needs (shown once), an RFC space when the goal is RFCs, and the command line's install for where it runs. Each step saves the answers so far, so a person who leaves resumes at the first open question; skipping leaves the welcome to continue from the overview.

The overview then shows a Getting started list for that template. A step is marked done from what exists (a key, a verified domain, an enrolled agent), never because someone ticked it.

A diagram is drawn here in the RFCs product; this page does not show diagrams yet.

Visibility

The door, the company home and the welcome are shown to admins and partners first. Opening any of them to everyone is the owner's decision, one at a time, and is recorded here. Until then the edge refuses them to everyone else, the same way it gates every unopened section.

Data and audit

An access request holds the person, their address, their company, their note and the decision. The welcome holds the chosen path, the choices and when it was finished or put aside, plus a team name when one is given. Neither is ever in a log, a metric label, a URL or a prompt to a model. Audit lines carry who, what and the outcome (access.request, access.decide, onboarding.save), never the note or an answer. A person's export lists their requests and their welcome answers, and erasing a person deletes both.

Open questions

  • The order of opening. Which comes first for the public: the door, the company home or the welcome.
  • Partner limits. Whether a partner's account carries its own plan and budget, or the free plan until a conversation sets one.
  • A booking link. The approval mail invites a conversation with an address; a calendar link is a later choice.

Alternatives considered

  • A separate company site on its own domain. Rejected for now: two builds, two sets of shared pages and a split sign-in, for a company home that starts as one page.
  • An anonymous access form. Rejected: it would need a public, unauthenticated endpoint with spam protection, and it would hold a stranger's data before they have an account. Asking signed-in people gives a verified address and nothing to abuse.
  • A customer role. Rejected: the people asking are prospective partners, and access given before any agreement or plan should say so. A customer is a later step.
  • Approval that only sends the NDA, as in RFC 0056. Rejected: the owner wants to talk with each partner, and the products, not only the reading sections, are what a partner needs to judge the platform.

Decision

Open. Built in four parts: this RFC, the partner role with access requests, the door with the company home, and the welcome.

Status log

  • 2026-10-05: opened. Proposed by the owner: the current site stays the personal site, the company site starts from a copy of its home page, a door between them, partners by request and NDA, and a welcome that sets a template up.
  • 2026-10-05: the company's home grew away from the personal one. Its sections are now the company's: the loop with each step's state and the first chaos verify verdict as it was recorded (a fail, an unsigned draft), what runs today marked live, preview or coming, a first engagement (one change proved on the customer's system), who the reader deals with (one founder, no paying customers yet, , SOC 2-aligned controls, not attested) and the pace counted from the published RFCs when the site is built. "Book a pilot call" sits beside the access buttons. Still admins and partners only; opening it is one switch with the edge's route, and the page then asks to be indexed.
  • 2026-10-06: built and live for admins and partners. The door and the company home (#345); the partner role, access requests and an NDA invitation that names the role it gives, approval recording the company as the agreement's party (#347); the console's welcome with a personal or team template and a Getting started list marked from what exists (#352). Partners open the RFCs product, Reliability, Connections and the developer tools for their own account; those products' calls already check the caller's role in that account, so no admin route opened. The partner role follows the preview's rules: only a signed agreement gives it, never a hand-set role, and revoking the signature ends it and the person's sessions. The access pages and the welcome come in Croatian too.
  • 2026-10-06: the company home is the first page for every reader the company gate opens for (the owner). An admin or partner on / goes on to /company/ once the site knows who they are, unless they chose the team's side in the header's switch; anonymous visitors and search engines stay on the personal home, which stays the canonical /. The first-visit door that asked Team or Company is removed; the switch stays.
  • 2026-10-07: the company's home is the site's front page for everyone, search engines included (the owner). / is the company page and /company/ redirects to it; the founder's home moved to /nevio/, reached from the header's Team switch. The page names RFCs without linking the Lab, which stays hidden, and links no closed page.
  • 2026-10-07: Checked: the door, partners, the welcome and the company page (#345, #347, #352, #400 and follow-ups) are live. #505 and #524 (the company page as the front page for everyone) are merged, not rolled: www runs ca05bc17. Open until they roll.
  • 2026-10-07: the console's overview and welcome rebuilt (the owner's call). The overview reads the active account's state at a glance, each number linking to where to act: units, failed calls, keys needing a look, unread notifications, and for admins and partners monitors down, open incidents, reviews waiting and agents online; what needs attention, recent notifications, the loop with each step's state from the same file as the company page, and the platform's last day for the admin. A person without a role sees where their access request stands. The welcome is a stepped first run that saves as it goes and resumes, makes the team, the first token and an RFC space in place, and ends on the overview with Getting started as progress. English and Croatian.
  • 2026-10-07: The menu marked the company home and the tools page "admin" for everyone, a signed-out visitor included: the lock mark followed an item's gated field, not whether its gate was closed, and both gates had been opened that day. The mark now shows to an admin alone and only on a closed gate (gateClosed, marked in ui/shared/site-nav.ts), on every host, with a test per audience in ui:shared:check.

This document mentions

Mentioned in

← Back to Platform