explaingit

dkl101001/bloomcore-basics

★ 0Audience · developerComplexity · 2/5ActiveLicenseSetup · easy

TLDR

Public scaffold for a receipt-native audit pattern. Ships JSON schemas, examples, and a small Python package for canonical hashing and receipt validation. The full BLOOMCORE engine is kept private.

Mindmap

mindmap
  root((BLOOMCORE-Basics))
    Inputs
      System events
      Schema files
      Previous receipt hashes
    Outputs
      Validated receipts
      Node readouts
      Replayable audit trail
    Use Cases
      Add audit trails to apps
      Adopt receipt patterns
      Validate hash-linked logs
    Tech Stack
      Python
      JSON Schema
      SHA-256

Things people build with this

USE CASE 1

Adopt a receipt-native audit pattern in an existing service

USE CASE 2

Validate hash-linked event logs against a published JSON schema

USE CASE 3

Generate inspectable readouts that pair with a private orchestration engine

USE CASE 4

Study a minimal Python implementation of canonical JSON and hash helpers

Tech stack

PythonJSON SchemaSHA-256

Getting it running

Difficulty · easy Time to first run · 30min

Repo is a scaffold rather than a runnable product, so you must fill in your own engine to see receipts flow end to end.

Apache 2.0 or MPL 2.0, both permissive open-source licenses that allow commercial use with attribution.

In plain English

BLOOMCORE Basics is the public-facing piece of a larger project called BLOOMCORE that its author has not released in full. The README is careful to say the same thing several times: this repository is not the complete system. The private parts, which the author refers to as the synthesis logic, orchestration, scoring, contradiction handling, and full assembly, stay separate. What is shared here is the public surface, meant to be inspectable and reusable on its own. The central idea is something the README calls receipt-native, audit-aware system design. The pattern works like this: when an event happens inside a system, a structured record called a receipt is produced. The receipt describes what happened, what state was involved, what hash anchors it, and what previous event it links to. Validators check the receipt against a schema, hashes are confirmed, and a readout is generated, leaving an inspectable audit trail. The point is that the engine running the system can be non-deterministic, with mutation and exploration and stochastic choices, while the record of what happened stays deterministic and replayable. The public layer in this repo contains JSON schemas for receipts, public node readouts, and validation results, plus example files for each. It also sketches a small Python package called bloomcore_basics with utilities for canonical JSON serialization, hash helpers, and receipt and readout handling. The README shows a suggested directory layout under schemas/, examples/, and src/bloomcore_basics/, and points to a minimal_run/ folder for a local demonstration. The license is listed as Apache 2.0 or MPL 2.0. The repository has 0 stars and the language tag is unset, which is consistent with a freshly seeded public scaffold rather than an active codebase. The README itself reads more like a position statement and a vocabulary document than a guide to running working code.

Copy-paste prompts

Prompt 1
Walk me through the receipt JSON schema and what each required field anchors to.
Prompt 2
Help me wire bloomcore_basics into a Flask app so every request emits a signed receipt.
Prompt 3
Show me how to extend the schema with a custom event type without breaking validators.
Prompt 4
Add a CLI that replays a folder of receipts and reports any broken hash links.
Prompt 5
Explain how to keep my engine non-deterministic while keeping the receipt stream replayable.
Open on GitHub → Explain another repo

Generated 2026-05-22 · Model: sonnet-4-6 · Verify against the repo before relying on details.