The EDGEBIC Schedule Change Log and Audit Trail

EDGEBIC records both schedule changes and security events: an accepted schedule change writes a change-log entry, and security-relevant events accumulate in an append-only audit trail inside the database, giving an administrator a traceable history of what changed and who was involved. In EDGEBIC by User Solutions traceability is not a bolt-on feature you enable. It is a pair of records the system keeps as it runs, and administering them is mostly about knowing they exist, what each answers, and the account hygiene that keeps them meaningful.

This post is the administrator's view of those records. For the full reference behind them, read the EDGEBIC admin guide, and for the access controls that make them trustworthy, see how role-based access protects the schedule. It describes records at the behavior level, never any internal path.

Two Records, Two Questions

EDGEBIC keeps two distinct audit records, and the cleanest way to hold them is by the question each answers.

• The schedule change log answers "what happened to the plan." When a schedule change is accepted, EDGEBIC writes a change-log entry, so the history of accepted reschedules is a record rather than a memory.
• The security audit trail answers "who did what to the system." Security-relevant events, like sign-ins and account or permission changes, accumulate in an append-only trail inside the database.

Keep the two separate and you always know which record to reach for. A dispute about when a job moved is a schedule-change question. A compliance question about who had access is a security-audit question.

The Schedule Change Log

Every accepted schedule change is recorded. That is the important word: accepted. EDGEBIC does not apply a proposed change automatically. A reschedule, or an optimizer proposal, is generated and reviewed, and only when a planner accepts it does it become the plan and write its change-log entry. So the change log is a record of decisions that were actually made, not of every draft considered.

This pairs with a rule planners rely on: completed work is never moved by a reschedule. Anything already logged as done stays exactly where it happened. So when you reconstruct a job's history, the completed steps are fixed points, and the change log tells you how the remaining plan moved around them. Between the two, "what was the plan, when did it change, and what actually ran" becomes a question you answer from records rather than recollection.

The Security Audit Trail

The security audit trail is an append-only record inside the database. Append-only means entries are added, never edited or removed, so the trail accumulates a permanent history of security-relevant events. It is the evidence behind questions like who signed in, when an account was created or deactivated, and when a permission changed.

One honest limitation to plan around: there is no in-app screen to browse the trail yet. It exists as a queryable record your administrator or support consults, not as a live dashboard. So when an auditor asks for it, plan the request as a query against the database, not a screenshot from a menu. The record is there and it is permanent; it is simply retrieved rather than browsed.

Both Records Depend on Account Hygiene

The single factor that determines whether these records are worth anything is account hygiene. Both the change log and the audit trail can only name whoever was signed in. If a plant shares one "planner" login, every entry names that shared account, and the records answer "someone" rather than "who." The traceability collapses.

So the foundation of a useful audit trail is laid months before any audit: one account per person, never a shared login, enforced through role-based access. This is why the roles material stresses individual accounts so heavily. The permission model is not only about restricting who can do what; it is also what makes the audit records able to attribute an action to a real individual. Deactivating a departing user rather than deleting them, covered in deactivating users and offboarding, keeps their historical entries attributable too.

What You Can Actually Answer

Put together, the two records let an administrator answer the questions that come up in practice.

The pattern across all of them is the same: EDGEBIC keeps the record as it runs, and your job is to know it exists, keep accounts individual so it stays meaningful, and retrieve it when a question arrives. That is a lighter burden than building an audit process from scratch, and it is why traceability in a scheduling system is worth having built in.

For the access model that underpins these records, read how role-based access protects the schedule, and for the broader operational context, see what production scheduling is. The full administrator reference is the EDGEBIC admin guide.