Integrations

Integration boundaries before integration claims

Ontogony’s public model distinguishes the direction of evidence flow, the authority of each input, and the point where secrets and private operations must stop.

  1. Source, evidence, policy, and approval systems

    Data and authority-system posture

    1. 01 →

      Evidence direction

      Declared source and authority evidence moves into bounded stages; promotion results may be projected outward only through approved contracts.

    2. 02 ⟂

      Authority

      External authority is named by contract; the adapter does not become authoritative by transport.

    3. 03 ■

      Public and redaction boundary

      Customer, employee, prompt, model-response, and held-back-truth material is denied by default.

    Secret boundary
    Connections, identifiers, credentials, and internal hosts remain private.
    Configuration posture
    Data and authority connections are described only as architectural classes.
    Evidence accepted
    • No customer, policy, or enterprise-system evidence is approved for public documentation.
    Limitations
    • No connector availability, customer deployment, or private integration status is claimed.
  2. Vendor evidence adapter

    Microsoft-origin evidence posture

    1. 01 →

      Evidence direction

      Vendor-origin evidence moves inward only through an approved collection, redaction, and projection boundary.

    2. 02 ⟂

      Authority

      Any future vendor-origin evidence remains non-authoritative input.

    3. 03 ■

      Public and redaction boundary

      Evidence must be redacted and publication-approved before it enters a public bundle.

    Secret boundary
    Credentials, tenant identifiers, private endpoints, and configuration remain outside the public site.
    Configuration posture
    Approval pending; no Microsoft support, partnership, certification, endpoint, or implementation status is asserted.
    Evidence accepted
    • No evidence class is approved for public documentation.
    Limitations
    • Detail route and external documentation remain withheld pending owner approval.
  3. Model access and governed execution

    Model and agent runtime posture

    1. 01 →

      Evidence direction

      Governed requests move outward; bounded call and execution evidence may return inward.

    2. 02 ⟂

      Authority

      Runtime and model output remain advisory and do not acquire semantic or promotion authority.

    3. 03 ■

      Public and redaction boundary

      Only publication-approved, bounded evidence may enter the public proof surface.

    Secret boundary
    Provider credentials, model configuration, prompts, responses, and private endpoints remain outside the public site.
    Configuration posture
    Provider and runtime configuration is not published or represented as available.
    Evidence accepted
    • No provider or runtime evidence class is approved for public documentation.
    Limitations
    • No model or runtime vendor support claim is made.
  4. Neutral mechanics and publication-safe export

    Observability and evidence-export posture

    1. 01 →

      Evidence direction

      Operational signals may support internal mechanics; only approved evidence projections move into public artifacts.

    2. 02 ⟂

      Authority

      Observability is mechanical evidence, not semantic truth or a readiness claim.

    3. 03 ■

      Public and redaction boundary

      Logs and traces require explicit redaction, allowlisting, and schema validation before publication.

    Secret boundary
    Internal hosts, trace identifiers, credentials, and private service detail remain outside the public build.
    Configuration posture
    No observability vendor, sink, certification, or implementation state is asserted.
    Evidence accepted
    • No observability export is approved for public documentation.
    Limitations
    • Public status is a publication ledger, not live service monitoring.