MALTIN

PROJECT AUTHORITY FOR AI DELIVERY

Turn client commitments into governed project truth.

Maltin turns project material into a reviewable Contract where accepted decisions, unresolved questions and later changes stay explicit.

what a model proposed

proposedA model may publish without review.
proposedCustomer data remains inside the existing CRM.
Human review

what a person accepted

not acceptedA model may publish without review.
acceptedCustomer data remains inside the existing CRM.

Nothing proposed by a model becomes project truth until a person accepts it.

Human authority. · Persistent Contract. · Explicit change.

See the frameworkSee a sample Contract

01 — THE SITUATION

Nothing crosses into Maltin project truth without review.

Client commitments may already exist. Maltin makes explicit what the delivery Contract accepts, leaves open or changes.

A client says what they need. Someone interprets it. An agreement formalises part of it. Decisions continue in meetings, tickets and prompts.

The question this product is built around: when several versions of what the project is coexist, which one is authoritative?

A design premise, not a measured claim about the industry.

the boundary

A model proposed. A person accepted.

Accept, correct, reject, or deliberately leave a determination open. A model may propose; it may not accept.

before

proposedA model may draft a response.
unknownWho may approve an automated customer update?
Human review

after

acceptedA model may draft a response.
open — deliberatelyWho may approve an automated customer update?

An open question crosses the boundary too. It is not an omission; it is a recorded state, and it stays visible downstream.

02 — DOWNSTREAM

What a Contract holds

Illustrative. A generic assistant, not a customer.

ContractQ1
acceptedCustomer data remains inside the existing CRM.
openWho may approve an automated customer update?
acceptedA model may draft a response.
not acceptedA model may publish without review.
every row carries who accepted it, and why

source → review → Contract

03 — SUCCESSION

A project changes. Its history does not.

A change crosses the same boundary. It does not reach back through it.

Q1 — unchanged

acceptedHuman approval is required before an external write.
Human review

Q2 — successor

acceptedLow-risk categories may be auto-approved under a defined policy.

the crossing: a person decides something new

  • Q1 is unchanged.
  • Unrelated accepted meaning is unchanged.
  • The successor records who decided, and why.

Maltin does not judge whether two accepted rules agree. It records that a person chose both.

04 — THE FRAMEWORK

The human remains the authority.

  1. 1

    Interpret

    Maltin proposes a structured reading of the project. You decide what becomes project truth.

  2. 2

    Review

    Accept, correct, reject, or deliberately leave a determination open. A model may propose; it may not accept.

  3. 3

    Compile

    The accepted state becomes a reproducible Contract Snapshot.

  4. 4

    Package

    The Contract is projected into an execution package: what is required, what is forbidden, what must not be assumed, and what would count as done.

  5. 5

    Evolve

    When a real decision changes, Maltin creates a successor Contract rather than rewriting the past.

Where Maltin sits

Maltin does not replace your MSA or SOW. It governs the operational project truth between the agreement and implementation.

MSA / SOWcommercial and contractual commitmentyours — Maltin neither reads nor writes it
Maltin Delivery Contractaccepted project truth and explicit open state
Delivery contextexecution package and implementation context

What the engine does, and what an engagement does with it

The engine

A governed Contract, projected into an execution package.

Packaged context. Not execution.

The engagement

The same accepted truth can serve client delivery documentation, technical delivery control and implementation context.

Used across the engagement by people. Maltin does not generate these.