Architecture concept

Live

Product mental models.

Use these models to read product nouns consistently before writing tutorials, references, examples, runbooks, or cross-product guidance. Each model explains what the words help you understand and where the current documentation boundaries start.

Model Snapshot

Product models
3
Core nouns
13
Claim level
Concept
Documentation status
Accepted

Mental Model Diagrams

ObjectDBRead the live S3 Core bucket and object path before using native version or manifest vocabulary.
  1. 01BucketS3-shaped namespace for current workflows.Live S3 Core entry
  2. 02ObjectPayload addressed by bucket/key operations.Live with listed limits
  3. 03VersionNative object-model history vocabulary.Pproduct boundary
  4. 04ManifestNative metadata and object-state planning term.Review-bound
Message BrokerFollow a private beta stream from records into replay, cursor state, and shared queue work.
  1. 01StreamNamed surface for publish, fetch, replay, and queue routes.Private beta
  2. 02RecordPublished message with IDs, payload, timing, and offsets.Route-backed
  3. 03ReplayRead records again from offset, time, tail, or SDK start.Broker-only term
  4. 04CursorSaved processing position for groups or named readers.Bounded by route limits and compatibility guidance
  5. 05QueueClaim, lease, ack, nack, retry, and dead-letter workflow.Private beta
LogDBTrace telemetry from accepted envelope through local WAL publication, retained segments, and bounded query.
  1. 01EnvelopeCanonical telemetry shape from endpoint or OTLP ingest.Live ingest term
  2. 02WALLocal write-ahead log before segment publication.Live local path
  3. 03SegmentManifest-controlled retained-record bundle and indexes.Storage boundary
  4. 04QueryAuthenticated search over local or configured S3 segments.Live with limits

Quick Map

Primary product concepts
ProductMental modelQuestion it answersFirst page
ObjectDBBucket, object, version, manifestWhere does this object payload live, and what shape is supported today?ObjectDB hub
Message BrokerStream, record, replay, cursor, queueHow does an event move, get read again, and become shared work?Message Broker hub
LogDBEnvelope, WAL, segment, queryHow does telemetry become retained records that can be searched?LogDB hub

Product Models

Bucket, object, version, manifest

ObjectDB

Live

Begin with the scoped S3 Core bucket/object path, then treat native object version and manifest language as preview-contract direction unless a reference page names the behavior.

Bucket
Meaning: An S3-shaped namespace for current bucket and object workflows.
Use now: Use for scoped s3-core-v1 bucket discovery, create/list behavior, policy subset copy, CORS, tagging, location, multipart, and object routes.
Boundary: Does not imply IAM parity, lifecycle, replication configuration, inventory, Object Lock, notifications, SelectObjectContent, ACLs, or website hosting.
Object
Meaning: A payload addressed through a bucket/key workflow, with metadata, tags, range reads, multipart state, and delegated upload shapes where listed.
Use now: Use for live S3 Core object CRUD, listing, metadata/tagging, checksum, ETag, range, multipart, and local request-limit language.
Boundary: Does not imply every S3 operation or customer durability, recovery, performance, scale, or support claim.
Version
Meaning: A native object-model concept and operation-adjacent identifier that must stay distinct from S3 bucket versioning support.
Use now: Use when explaining why native object-platform direction can talk about object history separately from the active s3-core-v1 compatibility profile.
Boundary: S3 versioning is excluded from s3-core-v1; do not publish customer-facing version-management guidance until public references and evidence exist.
Manifest
Meaning: A preview native object-model word for describing object state and related platform metadata beyond compatibility-facing S3 fields.
Use now: Use as planning vocabulary for native object model, placement, policy, and event-oriented discussions.
Boundary: Does not imply a public native manifest API, hosted control plane, automatic event delivery, or reviewed placement outcome.

Source scope: documented source scope

Stream, record, replay, cursor, queue

Message Broker

Private Beta

Think of the broker as private beta stream and queue workflows over one route surface, with replay and cursor concepts kept separate from external protocol compatibility claims.

Stream
Meaning: A named broker surface that holds records for publish, fetch, replay, cursor, group, and queue workflows.
Use now: Use for private beta stream create, describe, list, publish, fetch, storage inspection, and retention wording.
Boundary: Does not imply every external streaming pattern, Kafka listener support, or production topology outcome.
Record
Meaning: A published message with identifiers, payload, optional key, event time, ingest time, headers, offsets, and route diagnostics.
Use now: Use for publish acknowledgements, fetch pages, replay pages, queue deliveries, audit support details, and replication-status boundaries.
Boundary: Does not imply unlimited payloads, exactly-once cross-site behavior, or stable ordering outside the named route behavior.
Replay
Meaning: A controlled read of stream records from an offset, time selector, tail window, or SDK subscription start position.
Use now: Use for fetch/replay workflows, replay-consumer inspection, local CLI replay, and SDK subscribe-replay examples.
Boundary: Does not imply LogDB replay APIs, external sink delivery, Kafka consumer semantics, or selected pilot readiness.
Cursor
Meaning: A saved read position for a consumer group or named processing path.
Use now: Use for commit, rewind, cursor inspection, group lag, and reader coordination over broker stream records.
Boundary: Do not confuse broker cursors with LogDB query pagination or promise global consumer-state durability beyond the current route limits and compatibility guidance.
Queue
Meaning: A shared-work model built from claim, lease, ack, nack, renew, retry, and dead-letter operations over stream records.
Use now: Use for private beta queue worker flows, delivery mutation, retry, and dead-letter handling.
Boundary: Does not imply every queue pattern, remote CLI write support, or cross-site availability guarantee.

Source scope: documented source scope

Envelope, WAL, segment, query

LogDB

Live

Read LogDB as an OTLP-first logs/traces retention and query system, with segment storage and S3 query-read language separated from future S3 publication and BYOC claims.

Envelope
Meaning: A canonical telemetry record shape produced by endpoint JSON helpers or OTLP compatibility ingest, with deterministic record IDs where documented.
Use now: Use for JSON endpoint payloads, OTLP JSON compatibility batches, tenant admission, record IDs, and recent readback wording.
Boundary: Does not imply metrics/profile ingest, dashboarding, SIEM replacement, or arbitrary telemetry transformation.
WAL
Meaning: The local live write-ahead log path used before segment publication and during startup replay evidence.
Use now: Use for local publication ordering, startup replay, replicated-local proof slices, and process-fault evidence only when the source is named.
Boundary: Does not imply final distributed WAL, network replication, node-level failure coverage, or durability commitments.
Segment
Meaning: A manifest-controlled retained-record bundle with Parquet data, statistics, exact identifier indexes, retention metadata, and encryption metadata fields.
Use now: Use for local segment publication, segment-bundle v1 storage, retained query, and configured S3 query-read discussions.
Boundary: Configured S3 query-read changes the query read path only; it is not S3 publication or BYOC production readiness.
Query
Meaning: The authenticated retained-record search path over local or configured S3 segment bundles.
Use now: Use for POST /v1/query by dataset, exact record ID, exact trace ID, source time, ingested time, pagination, and deadline controls.
Boundary: Does not imply distributed query workers, cost controls, long-retention outcomes, public replay APIs, external sinks, or support commitments.

Source scope: documented source scope

Reading Order

  1. Choose The ProductStart with the product that owns the workload: object payloads, event movement, or telemetry retention.
  2. Name The NounsUse the product's core nouns before jumping into API routes, examples, or operations language.
  3. Check The BoundaryEvery noun carries a readiness label, evidence basis, compatibility row, or known-limit note.
  4. Write Narrow GuidancePromote a concept to task guidance only when source scope and product acceptance support the stronger claim.

Per-Product Reading Paths

ObjectDB

  1. Start with the bucket and object operation in the S3 Core reference.
  2. Check the compatibility row for supported, partial, unsupported, preview, future, or verification-required status.
  3. Use version and manifest language only with preview-contract or verification-required labels nearby.
  4. Attach topology, software version, hardware, and fault-model evidence before strengthening durability or scale claims.

Message Broker

  1. Create or identify the stream before describing records, replay, cursors, or queue work.
  2. Use replay for reading records again and cursor commit or rewind for processing position.
  3. Use queue language only when claim, lease, mutation, retry, and dead-letter routes are part of the workflow.
  4. Keep replication, Kafka, identity-provider, performance, and support claims behind selected evidence and support teams.

LogDB

  1. Start with the ingest route and signal scope: endpoint JSON, logs, traces, OTLP HTTP/protobuf, JSON compatibility, or optional gRPC.
  2. Use envelope and WAL language to explain local admission and publication order only within named evidence.
  3. Use segment language for retained bundles and query storage; separate local publication from S3 query-read configuration.
  4. Use query language for retained search, then keep replay, external sinks, S3 publication, BYOC, scale, and GA claims tied to owning-page evidence and review.

Do Not Infer

Concepts Are Not Contracts

A mental model explains how to read product language. It does not create a route, compatibility guarantee, support promise, or deployment architecture.

One Noun Can Have Different Status

Bucket, dataset, cursor, placement, segment, and replay words can mean different things across products. Use the owning page and readiness label before reusing them.

Examples Need Their Own Proof

Example, SDK, runbook, and integration guidance still needs source, smoke, fixture, release-note, or product source scope for the exact behavior it teaches.

Source scope

Source scope map
Model areaSource scopeStatus
Cross-product vocabulary and non-inference rulesdocumented source scope, product fact sheets, public status, limits, and compatibility pagesapproved
ObjectDB object, version, and manifest modeldocumented source scopeapproved
Message Broker stream, queue, replay, and cursor modeldocumented source scopeapproved
LogDB envelope, segment, and query modeldocumented source scopeapproved

Internal public documentation boundaries track these product mental models and their readiness labels.

Safe Next Steps

  • Available

    Read the system map

    Use the cross-product map to choose which product role owns the workflow before using these product nouns.

  • Available

    Use the glossary

    Check overloaded terms such as bucket, cursor, dataset, compatibility, and claim boundary before writing product copy.

  • Available

    Compare compatibility rows

    Confirm whether a noun describes supported, partial, unsupported, preview, future, or verification-required behavior.

  • Available

    Read known limits

    Check unsupported behavior before turning a mental model into a guide, example, reference, or runbook.