Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/HypathStack/model-scribe/llms.txt

Use this file to discover all available pages before exploring further.

ModelScribe ships two Artisan commands: model-scribe:prune for enforcing your retention policy and removing stale audit records, and model-scribe:make-table for scaffolding the database migrations needed when you add a new named log store. Both commands are registered automatically by the package’s service provider — no additional setup is required.

model-scribe:prune

Deletes stale audit log entries from every table managed by the target driver, according to the retention policy set in config/model-scribe.php. Signature
model-scribe:prune {--driver= : Prune a specific driver (default: the configured default)}
Description: Prune stale ModelScribe audit log entries according to retention policy.

Options

OptionRequiredDescription
--driverNoThe name of the driver to prune (database, file, stack, or any custom driver). Omit to use the value of config('model-scribe.default').

Examples

php artisan model-scribe:prune
php artisan model-scribe:prune --driver=database
php artisan model-scribe:prune --driver=file

Output

The command always exits successfully and prints the total number of records removed:
INFO  Pruned 342 audit log record(s).
If the driver’s retention type is permanent, or if the driver does not manage persistent storage (e.g. file), the count will be 0.
For a full explanation of how each driver handles pruning and how to schedule this command, see the Pruning guide.

model-scribe:make-table

Generates a Laravel database migration for an additional ModelScribe log table. Use this whenever you want to route a model’s audit entries to its own dedicated table via a named store. Signature
model-scribe:make-table {name} {--table= : Override the table name (default: {name}_scribe_logs)}
Description: Create a migration for an additional ModelScribe log table (store).

Arguments

ArgumentRequiredDescription
nameYesThe store name in snake_case (e.g. invoices, orders). This becomes the key in drivers.database.stores and the value you assign to $auditLogName on your model.

Options

OptionRequiredDescription
--tableNoOverride the generated table name. Defaults to {name}_scribe_logs (e.g. invoices_scribe_logs).

Examples

# Creates: database/migrations/{timestamp}_create_invoices_scribe_logs_table.php
php artisan model-scribe:make-table invoices

# Override the table name
php artisan model-scribe:make-table invoices --table=invoice_audit_trail
After the migration file is written, the command also prints a reminder showing the exact configuration snippet you need to add:
INFO  Migration created: [database/migrations/2025_06_01_120000_create_invoices_scribe_logs_table.php]
WARN  Remember to add the store to your config/model-scribe.php:
        'stores' => [
            'invoices' => ['table' => 'invoices_scribe_logs'],
        ],
The generated migration uses the same schema as the default model_scribe_logs table — including all optimised indices on subject_type, subject_id, causer_type, causer_id, log_name, event, and created_at. You get identical query performance on every named store without any extra configuration.

Follow-up steps

After running the command, complete the setup in three steps:
1

Run the migration

Create the new table in your database:
php artisan migrate
2

Register the store in config

Open config/model-scribe.php and add the new store under drivers.database.stores:
'stores' => [
    'invoices' => [
        'table' => 'invoices_scribe_logs',
    ],
],
3

Set $auditLogName on your model

Point the model at the new store by setting $auditLogName to match the store key:
use HypathBel\ModelScribe\Traits\HasAuditLog;

class Invoice extends Model
{
    use HasAuditLog;

    protected string $auditLogName = 'invoices';
}
All future audit entries for Invoice will now be written to — and pruned from — invoices_scribe_logs instead of the default table.
For the full guide on routing models to named stores, including multi-table stores, guard-based routing, and cross-database configurations, see the Multi-table routing reference.

Build docs developers (and LLMs) love