Arkus Innovation Studios

Ship Log 004 · The product around the product

This week we worked on the product around the product: access, proof, operations, trust boundaries, and the public surfaces that decide whether AI systems can survive real use.

This week we worked on the product around the product.

That sounds like a workaround phrase. It is not.

A product is not only the screen someone clicks. It is the access system that decides who belongs there, the billing path that decides what they can use, the report logic that decides what evidence is safe to show, and the operator surface that decides whether a failure is visible before a customer finds it.

The screen is the part people remember.

The surrounding system is the part that decides whether they trust it.

The access challenge

Arkus Insider kept becoming the front door for the suite.

Not just a login page. A control surface.

Access requests now have a queue. Codes are more tightly bound to the person meant to use them. Existing accounts can activate without burning a code on the wrong path. Checkout now routes through the same public path instead of living as a separate motion. Admins can grant, revoke, reconcile, and see more of what is happening across the suite.

This is not glamorous work. It is also the work that makes the glamorous parts usable.

The interesting failure mode was the first SSO handoff.

A one-time code could be consumed by an aborted or duplicated callback before the product actually received the session. The browser did what browsers do. It retried, preloaded, interrupted, or landed twice. The system treated that as a final answer.

The fix was not to make the code generally reusable. That would be easier and worse.

The fix was a short same-audience reuse window, plus stricter host canonicalization. Fifteen seconds of tolerance for the same product audience, while ordinary replay still gets blocked.

That is a small rule. It is also the difference between a member landing in the product and getting sent back to login for no reason they can understand.

The proof challenge

Index had the same shape, but deeper in the stack.

The visible product is a decision brief. The actual product is whether the evidence and session state can survive a real path through production.

This week, the auth proxy dropped the headers the client needed to refresh its JWT. Then a Vercel function crashed because a runtime ESM import missed .js. Then SSO users could authenticate but not see older reports, because the new portal user ID did not match the legacy report owner.

All three are different versions of the same problem.

The interface can look close to working while the system underneath has lost the thread.

So the fixes were specific. Forward the auth headers. Add a guard for runtime import extensions. Let SSO sessions resolve to a safe legacy report owner by verified email. Do not mint fake Better Auth sessions just because that would make the new path look like the old one.

After that, the report itself got stricter.

Patent searches stopped letting inc become a useful invention-title search term. FTO verdicts stopped anchoring on patents already cleared as false positives. Funding-stage logic moved into one shared model instead of living in one export path. The Patent Register became a working evidence surface, not a thin table with a confident name.

A diligence product does not get credit for sounding certain.

It has to explain why it is certain, where it is uncertain, and which evidence actually moved the answer.

The operations challenge

VentureIP had the quieter version of the same lesson.

A communications migration was marked as applied. The physical fund_communications schema was missing. The admin health check did not catch it, because it was checking migration status, not the real schema underneath.

That is a useful bug.

Not pleasant. Useful.

The fix was to make the health check look for the table, enum types, and indexes that the feature actually needs. A green migration record is not the same thing as a working system. It is only a record saying the system believes something happened.

Systems are allowed to believe false things. That is why we check.

The rest of the VentureIP work followed the same operating pattern: error boundaries, migration runner, telemetry retention, legal posture, fund-scoping tests, portal updates, and admin communications.

None of those are the headline feature.

All of them decide whether the headline feature survives real use.

The boundary challenge

Arkus AI closed a more direct trust boundary.

The Gemini key moved out of the browser bundle and behind an authenticated ephemeral token endpoint. The token is short-lived, issued server-side, scoped to the Live model, and fetched per connection.

That is the right shape.

Then voice sessions started closing with 1011 shortly after connecting. The token flow worked. The connection worked. The failure was narrower: the token constraints were locking more of the Live session configuration than intended.

The fix was a field mask. Lock the model, not the entire session setup.

This is not a sentence anyone would put in a launch announcement. It is still the reason the session stays open.

The public-surface challenge

The website also had to catch up to the product.

Routes changed. Pricing claims were reconciled. Member login and request access became part of the public path. Shared-link metadata moved to build-time output instead of relying on the browser. The Ship Log archive kept growing.

Some of this is boring in exactly the right way.

A public website should not say waitlist if the product is live. It should not route pricing to a dead end. It should not depend on a client-side head tag to explain itself to LinkedIn. It should not expose product paths that no longer match how the system works.

Public trust often fails in places that look like housekeeping.

A stale redirect is a product bug if it sends the wrong person to the wrong surface.

The larger pattern

Different repos. Same pattern.

We were not adding more AI for the sake of adding more AI.

We were making the system around the AI harder to misunderstand.

Which domain owns the session.

Which product can accept a handoff.

Which code can be reused, and for how long.

Which report claims were retrieved, inferred, or cleared.

Which admin action changes billing, not just local state.

Which health check proves the schema exists, not just that a migration row says it should.

Which model credential is safe to put in a browser. The answer is still none.

A demo can survive ambiguity.

A production system cannot.

Back next week.

Sheldon