MARMATIONDiscuss a project
MARMATION

Start with the job.Then choose the architecture.

Discuss a project

AI Consulting & Product Engineering

Proof has
a structure.

A beautiful interface can suggest a capability. It cannot establish that the underlying system is correct. Marmation Lab exists to make the architecture, assumptions, tests and limitations behind a technical idea visible.

Start with what works
Marmation LabOne working local sliceTwo unbuilt reference designsNo client-system claims
Implemented local slice

The document cannot
approve itself.

A fabricated purchase order becomes a reviewable transaction. Inspect its source, correct a field, authorize one revision, then see what happens when the commit fails.

Open the document workbench

Deterministic rules. Synthetic data. In-memory destination.
No AI provider, authentication service or external business writes.

Implemented local control path

  1. InputFabricated documentText supplies values, never permission.
  2. InterpretationSix labeled fieldsExact matches with source lines. No inference.
  3. AuthorityRules + reference registerMissing values and unknown IDs hold the order.
  4. DecisionExplicit human approvalOne field revision. Edits or revocation clear it.
  5. ActionGuarded local commitFailure stays visible. A retry is explicit.
  6. EvidenceReconciled memory recordRepeat commit returns the existing record.

A failed or revoked attempt cannot advance itself.

Intelligent Document OperationsThe wider reference architecture remains a concept.

A small, inspectable
body of evidence.

15 fabricated fixtures
Six ordinary orders, three missing-data cases, two unknown identifiers and four control exercises. Fixed inputs; no customer data.
18 state-machine tests
The local state-machine suite checks guards, corrections, revocation, retry, duplicate prevention and reconciliation. It is separate from the browser exercise.
One browser session
State lives in memory. Reset or reload discards it. The role selector illustrates guards; it does not authenticate a person.

Two questions
still on paper.

These designs propose different systems and different proof obligations. Neither has an implemented application or executed test results.

Concept · not implemented

Permission-Aware
Enterprise Knowledge

Can the same question produce the right answer for two people with different access?

Inspect the access boundary

Proposed evidence boundary

Employee identityCurrent access rulesAuthorized evidence

Restricted text must stay outside retrieval results, inference and secondary logs.

Planned: three fictional identities · 30 synthetic documents
Concept · not implemented

AI Product
Review Workspace

Can an intelligent suggestion remain useful inside a product’s state, permissions and recovery paths?

Inspect the product contract

Proposed versioned decision trail

  1. SuggestionProposed
  2. User judgmentEdited / rejected
  3. Domain actionApproved → committed

Source, suggestion and final decision stay separate. A lost connection must not erase the draft.

A beautiful interface can suggest a capability. It cannot establish that the underlying system is correct. Marmation Lab exists to make the architecture, assumptions, tests and limitations behind a technical idea visible.

The situation behind the request

A permission-aware knowledge assistant may look simple until one employee is blocked from a document another can use. An operational console may look elegant until an ERP API fails after an approval is committed. These are the cases that determine whether software is dependable.

Where the obvious solution falls short

Marketing demonstrations often show only the ideal user and the ideal input. A technical evaluator needs to inspect what is simulated, which components actually function, which tests ran and what remains unproven.

How we would approach the work

Lab entries separate concept from implementation and test status. Each contains architecture, synthetic data provenance, expected behavior, negative cases and limitations. Only actual working artifacts may be described as built or tested.

What the engagement may include

  • Permission-aware enterprise knowledge reference application.
  • AI-powered B2B product review workbench.
  • Intelligent operations and exception console as expansion concept.
  • Architecture decision records and evaluation notes.

The choices worth making explicitly

These are not client case studies. Some Lab entries will remain concepts until code exists. Claims about performance, security or production readiness require real evidence.

What we would test before calling it ready

Each built entry requires a reproducible test checklist, implementation notes, screenshots from the actual app and explicit scope boundaries. Do not fake API integration or imply real customer data.

A sensible first step

Explore the decisions behind one reference application, or bring a real system problem to a first project discussion.

Bring us the
difficult part.

A product idea, a broken workflow, scattered company knowledge or an integration others keep working around. Tell us what needs to change and what has already been tried.

Discuss a project