Documented interfaces of each OmniOmni component and the OmniGENIE role in development
All OmniGENIE integrations are in development. Today no code yet connects the GENIE platform to an OmniOmni component today. For each component, this page states the interface that is documented today, the OmniGENIE role in development, and what stays with the component and with people. No endpoint is named here that is not part of the component's published API reference.
Read to prepare. OmniGENIE reads documented context to prepare summaries, case files and draft actions.
Write only on the existing path. Any write or transactional action is a prepared action handed to the component's authorised mechanism. Sensitive calls in OmniOmni are signed through the Proof-of-Action (PoA) mechanism, a cryptographic signature created with the user's private key in OmniPersona. Not to be confused with Proof-of-Authority, a blockchain consensus mechanism listed in the glossary.
No duplication. OmniGENIE does not replicate detection, scoring, register or custody functions.
Read access to assets, register transactions, investments and documents through the OmniAsset API with bearer authentication. Write and signing operations carry Proof-of-Action signature headers and idempotency keys. See Integration scenarios and API usage considerations.
OmniGENIE role (in development)
Read asset, register-transaction and investment context to prepare summaries, drafts and validated inputs for register-relevant workflows such as corporate actions.
Stays with the component and with people
Registration, transfers and any register write are executed by OmniAsset on the existing Proof-of-Action-signed path after human approval. The register is operated by a licensed registrar.
Read access to balances and transfer status. Signing requests are asynchronous and require approval by the wallet owners through Proof-of-Action. See OmniSafe.
OmniGENIE role (in development)
Surface custody status as context. Prepare a signing request that is then approved by the wallet owners.
Stays with the component and with people
OmniGENIE cannot sign and has no access to key material. Custody is performed by licensed custodians.
Read access to identity and transaction assessment results and to the process history of an assessment. Risk overrides are human actions on the component's interface. See OmniEagle.
OmniGENIE role (in development)
Explain existing findings in context, assemble case files with references, flag missing items and prepare handovers.
Stays with the component and with people
Detection, screening, scoring, overrides and suspicious-activity reporting remain OmniEagle functions and compliance-officer decisions. OmniGENIE does not produce or alter risk scores.
Sign-up, identity verification (including PostIdent), one-time passwords and Proof-of-Action signing with a device-bound key pair. See OmniPersona and the Proof-of-Action mechanism.
OmniGENIE role (in development)
Request approval of a prepared action through the existing Proof-of-Action flow, so that the authorised user reviews and signs in OmniPersona.
Stays with the component and with people
Identity verification and authorisation remain with OmniPersona and the user. OmniGENIE does not replace identity checks and does not hold signing keys.
OmniApp (white-label investor application): any integration would run through the OmniAsset layer, not through the application itself.
OmniWiki (knowledge base): institutional knowledge search over OmniWiki content is a candidate use case. No content interface exists today; ingestion would be a content pipeline.
A dedicated OmniGENIE client role and scopes in the OmniOmni authentication model
Least-privilege read access per component.
A prepared-action handover to the Proof-of-Action flow
Human approval of OmniGENIE-prepared actions in OmniPersona.
Provenance links from memory items to component records
Traceability of facts that originate from OmniOmni data.
An oversight view in OmniBoss
Review of OmniGENIE operational artefacts by administrators.
OmniGENIE is designed to coexist with ecrop's internal work on agent governance within the OmniOmni backend rather than replace it. No public interface from that work is documented yet, and none is referenced here.
