Bonfÿre is the software we use to build and operate Aurekai. It handles the things our different products need in common: people and organizations, their records, business applications, external information, models, agents, transactions and public websites. The same identity or record can appear in several places while each application keeps control of its own work.
Think about a publisher, a business or an item for sale. It may have a public page, a workspace record, an API address, material in a feed and relationships to other people and organizations. Bonfÿre's Matrix keeps the subject and its relationships together so a change to its identity or relationships can be reflected across its different views. This is similar to the problem GS1 Digital Link addresses for products: one identifier can point to several kinds of useful information. Matrix applies the idea more broadly to people, organizations, publications, accounts and work.
An address is more than a URL. The same subject might appear under an Aurekai subdomain, a customer's own domain, an internal account application or an external API. Which parts someone can see depends on the account, the audience and the state of the record. Matrix and Bonfÿre's address owners handle those relationships. The web renderer then builds the view appropriate to that destination.
Shared subject identities, addresses, relationships, organizations and the original material behind a record. A profile and a job listing can refer to the same company without inventing two companies.
Matrix architecture ↗Each account has its own installed applications and records. CRM handles relationships; finance handles money; a creator studio handles media; a catalogue handles products. They can share references and continue work across one another.
Application families ↗WorkGraph manages tasks, dependencies and recovery. CapabilityClosure matches each step with an available implementation. The native tool, model, agent or remote application does the work under that destination's rules.
Execution architecture ↗Bonfÿre is built across native application infrastructure, data systems, agent tools, media, models and commerce. This inventory comes from the installed Bonfÿre V6.1.0 and Architecture Atlas on November 7, 2026.
ERPNext, CRM, HRMS, Helpdesk, LMS, Wiki, Drive and Insights grammar integration, account destinations, records and workflows.
People, organizations, addresses, collections, publications, listings, retained sources and relationships across products.
Dependent work, native commands, models, agent orchestration, resource admission, schedules, automation and replay.
Transcription, speech, audio and video, channels, creator studios, content processing and distribution.
Products, catalogues, prices, procurement, accounting, payments, offers, markets and configurable spatial shopping.
Local models, FPQ, SIMD/native backends, warehouse/query tools, embeddings, structured analysis and external compute providers.
| Installed V6 / Atlas | Recorded scope |
|---|---|
| Native command families | 93 |
| Frappe-derived DocTypes | 1,840 across 51 modules |
| WorkGraph | 20,487 nodes / 45,412 edges |
| Active backend adapters | 14 |
| Architecture Atlas | 556 entries: 346 implemented, 152 measured, 24 declared, 34 architectural |
One of our ongoing integration examples starts with a job posted by a company. Several Aurekai applications may want to work with that information, but they don't all have the same job.
The source system retains the posting and the company it belongs to. The public discovery page can show the opportunity. An account's CRM can use it as a relationship or sales opportunity, if that installed application accepts this kind of item. A media tool might use the same text to prepare a narrated update. Each application receives the part it needs and keeps its own work; it doesn't take over the original listing.
That sounds simple when it's one record. It becomes harder across thousands of publishers, companies, catalogues, identities, accounts and external services. Bonfÿre handles the common address, application and capability relationships so each new continuation doesn't need its own custom integration from scratch.
Company + original job listing
├── Public discovery and company profile
├── Account CRM, when that app accepts job records
└── Media/narration tool, when installed and requested
Each application manages its own information and work.
The installed V6.1.0 inventory includes 93 native command families. The Frappe application sources contribute 1,840 DocTypes across 51 modules, covering ERPNext, CRM, HRMS, Helpdesk, learning, documents and analysis. WorkGraph holds 20,487 nodes and 45,412 edges. There are 14 active backend adapters. These are different parts of the implementation, not a single binary or one standalone app.
| Area | Owner concerns | Inspect |
|---|---|---|
| Data & CMS | SQLite, source-preserving records, query, indexing and retained source state | Native commands |
| Work & authority | WorkGraph, leases, capabilities, grants, scoped execution and final effect decisions | Architecture |
| Media & creator | Source intake, transcription, processing, narration and reviewed publication | Creator example |
| Business apps | Frappe/ERPNext/CRM/HRMS/Helpdesk/LMS/Insights/Wiki/Drive grammar projection | Integration source |
| Web & experience | Matrix addressing, SurfaceIR, public readback, products and account-scoped editors | Product index |
| Compute | Model routes, optimization, agents, physical resources and placement | Model systems |
A task starts with a goal and a destination. WorkGraph tracks the dependencies and stages. CapabilityClosure identifies the native command, installed application, model, agent or outside service that can perform each part. Claude Code, Codex and local models are possible workers alongside deterministic C tools. The receiving application decides what information it accepts and what action the operator may take. The 2026 Stanford AI Index found widespread organizational AI use in 2025 but much earlier deployment of AI agents inside specific business functions; that's the kind of practical integration gap we're engineering for.
Applications and providers expose declared capabilities. A reachable service is not permission to read, spend or write.
MCP source ↗Typed dependencies, recovery, admission and effect review replace implicit “someone checked the ticket” assumptions.
Execution model ↗A cost estimate is not expenditure; a quote is not a paid invoice; a proposal is not accepted work.
Operating contract ↗Model Commons deals with the practical details of running models: loading weights, choosing a machine or backend, using a tokenizer, managing context, compressing and quantizing models, and evaluating the result. Other Bonfÿre components handle speech, transcription, audio, video and publishing. These services are available to the applications that need them.
Quantized and aligned model representations are workload- and quality-dependent research/engineering concerns—not a universal compression guarantee.
Inspect FPQ source ↗Retained context and cache behavior require explicit compatibility, model identity, freshness and invalidation checks.
Context architecture ↗CPU, Metal, accelerator kernels and external backends offer different feasible realizations. Probe the current environment and price/capacity.
Source & tests ↗The Architecture Atlas currently lists 556 entries, including 346 marked implemented and 152 marked measured. Entries link responsibilities to actual source and tests. GitHub Actions builds the public source, and the separate deployment processes release and check the public websites. The installed local runtime and a website can be on different revisions.
| Engineering state | What it records | Scope |
|---|---|---|
| Declared | A named contract and architectural owner | That a callable implementation exists |
| Implemented | Source, version, direct tests and supported dependencies | That a remote service is running |
| Measured | Test protocol, corpus, baseline, hardware, results and witness | General performance across unrelated tasks |
| Publicly deployed | Exact release and destination readback | Successful customer completion or settlement |
| Commercially completed | Acceptance, invoice/payment and actual deliverable records | Universal deployment or endorsement |
Historical FPQ and performance experiments are retained in the research archive. Current implementation details, versions and source links are documented in the technical references.
These articles came out of the actual implementation work: native model runtimes, application grammars, parallel coding agents and shipping public experiences.
Taking the useful business vocabulary of DocTypes into native applications.
Read the article ↗Planning, implementation, review and separate source revisions.
Read the article ↗Why public delivery has to follow the destination rather than the build log.
Read the article ↗Explore the native source, architectural registry and component families. The public GitHub source and installed operating runtime are maintained as separate versioned cuts.
git clone https://github.com/Nickgonzales76017/bonfyre.git cd bonfyre # Inspect the canonical registry and current source bun architecture/atlas.mjs validate bun architecture/atlas.mjs summary bun architecture/atlas.mjs expand ExecutionView # Optional, pinned public donor inventory bash scripts/federated_modules.sh list bash scripts/federated_modules.sh status products