Execution & authority
The model proposes typed operations over an editable-target catalog. Local code rejects invalid operations and validates the complete profile before rendering.
Inspect the execution boundarySystems & AI infrastructure
Engineering
at Axelyn
Systems engineering. AI infrastructure.
Reliable software depends on execution, state, observability and recovery. Axelyn publishes the decisions behind its systems, with an increasing focus on infrastructure for AI workloads. Start with the working Forge architecture, then inspect the areas under investigation.
Implemented engineering / Axelyn Forge
The system around
the model.
Forge is a working private document workflow using external model APIs. Its published architecture explains how application code controls evidence, model authority, artifacts and deployment. The private interface serializes work; its operational limits are part of the document.
Canonical data, evidence and templates define what may change.
- Verified evidenceCandidate facts & sources
- Model proposalConstrained rewrite operations
- ValidationDeterministic checks & rendering
- PublicationComplete output package
Operational controls
Profile isolation · Serialized private jobs · Usage ledger · Health-checked releases
The application validates model proposals and publishes complete artifact packages. The documented workflow runs as a private service, with serialized jobs and external model APIs.
State & isolation
SQLite indexes known evidence. Private profiles use separate state and output directories, while the Discord interface serializes tailoring work.
Inspect the state boundariesObservability & usage
Model requests create usage-ledger entries before execution. Failed and interrupted requests remain visible; completed records can include duration, tokens and estimated cost.
Inspect the operational recordDeployment & recovery
A constrained container runs a tested commit. Immutable releases are promoted after a health check, with the previous release restored if the replacement fails.
Inspect deployment and rollbackEngineering work
The decisions,
open for inspection.
Each entry identifies the system's status separately from its published documentation. A proposal describes an approach to validate; it does not establish a working implementation.
Architecture note · v0.2.0
Axelyn Forge
Working implementation
Working private system · Public blueprint
How Forge turns verified career evidence and a job description into a tailored resume and cover letter without giving the model control of candidate facts or document layout.
- Keep verified facts, document structure and layout outside the model's authority.
- Validate typed rewrite operations before rendering and publish the complete output package atomically.
The production system and candidate data remain private. This page publishes the operating pattern, control boundaries and known constraints.
Read the architectureArchitecture note · v0.1.0
Florist Order & Fulfilment System
Research proposal
Proposed system · Public blueprint
A system for independent florists to keep the agreed bouquet design, payment, card message, delivery details and later changes together from the customer's first request to collection or delivery.
- Keep payment verification and production status separate.
- Carry one current order through preparation and fulfilment with role-specific information boundaries.
This is a proposed operating blueprint. It describes the first-version workflow, information boundaries and measures to validate before a full build.
Read the architectureArchitecture note · v0.1.0
Florist Bouquet Costing & Purchase Planner
Research proposal
Proposed system · Public blueprint
A planning system that connects bouquet recipes, current material costs, usable stock and confirmed orders so a florist can review pricing and prepare one consolidated purchase list.
- Separate direct cost and contribution from net profit.
- Use current unit costs and confirmed demand while leaving prices and supplier orders under owner control.
This is a proposed operating blueprint. Its calculations depend on current supplier costs, consistent unit conversions and practical usage estimates maintained by the florist.
Read the architectureAreas of investigation
From application controls
to systems questions.
These areas guide ongoing learning and future experiments. Distributed scheduling, inference serving and performance evaluation require their own implementations and reproducible evidence before results can be claimed.
- Distributed systems
- Coordination, consistency and the behaviour of systems across process and network boundaries.
- Fault-tolerant execution
- Retries, idempotency, durable state and recovery when work is interrupted.
- Backend and infrastructure engineering
- Maintainable services, explicit interfaces and operational ownership.
- Data pipelines and ingestion
- Collection, validation and traceability from external inputs to usable records.
- Systems observability
- Useful signals for understanding failures and deciding what needs attention.
- AI workload infrastructure
- Workload scheduling, execution state, cancellation and resource boundaries for model-assisted tasks.
- Applied AI reliability
- Evidence, constrained model authority, deterministic validation, evaluation and human review.
Delivery evidence
What operation teaches.
Monitorscape documents multi-source ingestion, validation and backend failure handling. Pastelocity connects business records and operational handoffs. Memora brings together private event access, media handling and production infrastructure.
Read the implementation case studiesFuture experiments
Publish the method.
Show the limits.
Future work will use the same structure: the question, system status, design decisions, evidence and known limitations. Further reports, benchmarks and open-source releases will appear here when there is work to inspect.
- Architecture notes
- Interfaces, data flow, failure boundaries and design tradeoffs.
- Technical reports
- A defined question, method, observations and unresolved issues.
- Benchmarks
- Workload, environment, reproducible method and measured results with limitations.
- Open-source projects
- Code, licence, setup instructions and an explicit maintenance status.
- Engineering experiments
- Hypothesis, prototype scope, evaluation and what remains unproven.