Altruistic AI

Cases: an organization

An organization can have durable teams and temporary projects. These notes examine what should carry between them and what should remain separate. They are design cases, not a catalogue of commercial services.

Why a graphStable teams and temporary missions can coexist

We store an organization as a graph of sovereign nodes and explicit links, never as a set of boxes people must move between. A person can keep a stable team role while joining a time-bounded task force with named authority. When the mission ends, its links expire; the person, their work, and the institutional memory stay where they belong. Restructuring changes relationships, not accounts or archives.

A concrete operating model One company, two structures in use at once Stable teams keep accountability. A 90-day regulated-market launch adds a temporary, cross-functional mission.
Stable structure Four accountable teams Accounts, work history and ownership live here.
  • ProductProduct lead · Engineer
  • CommercialSales lead
  • CustomerSupport lead
  • GovernanceRisk partner
Temporary structure · 90 days Regulated-market launch The same people assemble around one outcome.
  1. Product leadMission lead
  2. EngineerBuild & integration
  3. Sales leadMarket readiness
  4. Support leadSupport readiness
  5. Risk partnerApproval gate
People stay put
The launch creates no new account and moves nobody between teams.
Work history stays put
Each record remains attached to its existing owner and context.
Mission links change
The five grants expire on day 90 or can be revoked earlier.
This is what “the structure is generated” means in practice: one person can hold a stable team role and a bounded mission role without being moved into a new container.

ScaleWhat the company learns should help the next person

In most companies each new hire adds onboarding burden, and each departure takes knowledge away. In this architecture what a company learns — the onboarding that finally worked, the safer procedure, the workflow that survived contact with reality — can accrue to the company's own node. The aim is for each authorized future employee to begin with more verified capability, not more copied personal context.

One concrete learning loop A lesson becomes institutional capability The value is visible in the trace from a real event to the next person.
  1. ObserveWork reveals a gapSupport finds a missing escalation step during the launch.
  2. VerifyThe team agrees on the fixSupport and Risk approve a safer response.
  3. RetainThe company records the lessonPlaybook v2 names its owner, reason, date and source.
  4. ReuseThe next person starts aheadHire #101 receives the corrected checklist on day one.
Institutional capability grows when a verified correction becomes a reusable company resource—not when private employee context is copied.

Institutional learning only works if it remains separate from personal context. Each employee’s private substrate stays theirs. Only information covered by an explicit grant crosses into the company context, and both sides can inspect what was shared, for what purpose, and for how long.

A person’s own AI can participate through the same interface. The company receives a bounded, revocable work projection rather than the person’s full history. When the relationship ends, the grant ends; personal memory remains with the person. A verified procedure becomes a separate company resource with its own owner and provenance.

Two ownership paths What the company may spread; what the person keeps The difference is ownership and policy, not a promise hidden in terms of service.
Company-ownedOnboarding, procedures and handbookInstitutional knowledge with a named owner.
Published through company policy
Available toAuthorized teams and future hiresIncluding hire #101 on day one when policy permits.
The employee can inspect what crossed; the company can show the governing grant and audit trail
Employee-ownedPersonal memory, private notes and personal agentTheir sovereign node, not an HR record.
No crossing by default
At workOnly a bounded projectionExplicit, revocable and audited consent is required.
Company capability can compound without absorbing the person. The two lanes are legible, governed and verifiable by both sides.

Client safetyA vendor relationship designed for replacement

The architecture is publicly described. Your deployment is a node that belongs to itself — it does not belong to us. Exit is a design requirement. Signed export is available and testable. Automatic one-step re-instantiation on a replacement deployment remains in development. The vendor relationship should remain safe even when you replace us.

Sovereignty includes the name. A private deployment — a government's, a regulated enterprise's, an air-gapped site's — may present as its own system entirely, under its own identity, models and policies. Nothing in the architecture requires it to expose a relationship to us, to any public implementation, or to any public infrastructure. The architecture permits this; fully independent deployments remain a future offering.

Altruistic AI is not a company. Commercial engagements are carried by Sathi Systems, the company behind Sathi. It is paid for adaptation — deployment, integration, migration off legacy systems, maintenance, operations and training — not for creating technical or contractual lock-in.

An open case

A worker leaves a project but still belongs to the organization. Which records, responsibilities and permissions should remain? A shared graph can represent the relationships; that alone does not settle who should control them.