Professional Information Is Not Shared Context

Professional work is built on information that cannot be treated as general AI context. A client's matter, instructions, documents, professional credentials and work history should not appear in another client's session merely because both people use the same platform.

This is a foundational operating principle for Anunnaki.Live: one client's authenticated workspace is not another client's context window. ABOS is intended to preserve professional continuity without converting all professional information into a shared pool of memory.

Identity comes before access

Protected areas of Anunnaki.Live begin with an authenticated identity. The platform identifies the user making the request and checks active membership before allowing access to governed areas such as matters, evidence, ABOS Memory and governed work.

A sign in is not blanket permission to inspect platform records. Access is assessed against the identity attached to the request. In practical terms, the platform retrieves a professional's matters, ABOS Memory entries and governed work runs only where the stored owner matches the authenticated user.

The intended result is clear: a user enters their own workspace, not a general database view.

Ownership is a data boundary

Professional information is stored with an ownership reference. That pattern applies to matters, uploaded evidence, ABOS Memory entries, governed work runs, identity passports, authority credentials and professional profiles.

When a protected record is requested or changed, the application checks that the record belongs to the authenticated owner before returning or updating it. A record identifier by itself is not authority. Knowing or guessing an identifier must not give another client access to a professional matter, document or work run.

An identifier locates a record. Identity, ownership, purpose and authority determine whether it may be seen or used.

Sensitive documents are bound to an owned matter

Evidence is handled as professional material, not as generic file storage. Before accepting an upload, Anunnaki.Live checks that the selected matter belongs to the signed in professional. The evidence record is then written with the same owner reference and the file is placed under an owner and matter specific storage path.

The application also limits accepted document types and file size, calculates a cryptographic digest of the captured bytes, and records a capture event. Credential evidence is additionally subject to identity and review gates. Where credential evidence is returned for inspection, the response is marked private and not to be stored by intermediary caches.

A digest proves the identity of the captured bytes. It does not prove truth, authorship, completeness, admissibility or current authority. ABOS keeps those distinct questions separate.

ABOS Memory does not override confidentiality

ABOS Memory exists so a professional does not need to rebuild a matter from scattered messages, meetings, documents and system activity. It can hold working context, instructions, decision context and candidate evidence for the owner who captured it.

Stored context is not automatically evidence, authority or permission to act. Each memory entry remains owner scoped. It is not injected into unrelated client sessions, and it does not become available to another professional merely because it exists on the platform.

• Memory preserves continuity.
• Evidence must be identified and admitted.
• Authority must be current, bounded and in scope.
• Human judgment remains reserved where the work requires it.

Governed work adds further gates

Some professional information needs more than an ordinary sign in. Credential submission requires an appropriate identity state before professional, organisation or authority evidence can enter review. Governed work checks the professional's current identity, credentials, evidence basis and approval state before it can progress.

The built in governed work runtime is deliberately bounded: it prepares internal work packets and records the decision path. It does not silently acquire authority to publish, file, purchase, send or alter an external system. Those actions require separately configured execution and verification boundaries.

Material transitions are recorded as ABOS events, forming a Replay trail of what was presented, what was checked, what was decided and what state followed.

Declared collaboration is different from accidental exposure

Some workflows require a defined disclosure: for example, an authorised participant may be invited to a workroom, or an authorised reviewer may inspect a credential submitted for independent review. Those are declared access paths with a stated purpose. They are not a general right for one client to browse another client's professional information.

Anunnaki.Live must continuously distinguish between information a client has chosen to disclose for a defined purpose, information available to an authorised reviewer under a defined role, and information that remains private to the client's own workspace.

What we can say honestly

The current application applies authenticated, owner scoped access controls to its protected records and does not treat client information as shared session context. Under those controls, a client should not see another client's protected professional information in an unrelated session.

That is a strong application level tenancy control. It is not an excuse for an absolute promise without continuous verification. Security requires ongoing cross tenant access testing, authorisation review for every protected route, private storage policy review, logging of sensitive actions and independent assessment as the platform grows.

The enduring commitment is therefore practical rather than rhetorical: information must be tied to authenticated identity, ownership, purpose and explicit authority. ABOS may preserve continuity for professional work, but it must not make confidentiality optional.