diff --git a/proposals/new/audit_log.md b/proposals/new/audit_log.md
index f1929918..f5ca328b 100644
--- a/proposals/new/audit_log.md
+++ b/proposals/new/audit_log.md
@@ -28,7 +28,7 @@ The audit_log table because of it is large size, it requires the DBA to create a
 
 ## Proposal
 
-Purge the audit log with a specified schedule, for example, every day at 00:00:00, or every week at 00:00:00. it could specify the operations need to delete and the retention hours need to keep. user could schedule the job to delete the audit_log records manually or periodically. if the audit log retention hours is set to 0, it means the audit log will be kept. 
+Purge the audit log with a specified schedule, for example, every day at 00:00:00, or every week at 00:00:00. it could specify the operations need to delete and the retention hours need to keep. user could schedule the job to delete the audit_log records manually or periodically. if the audit log retention hours is set to 0, it means the audit log will be kept.
 
 The purge audit log job could be scheduled by cron job or manually. after executed the job, the purge job history could be retrived by the API.
 
@@ -137,11 +137,6 @@ func (h *Handler) Handle(ctx context.Context, value interface{}) error {
 
 #### Purge the audit log table
 
-In the harbor core main function, start a go function to purge the audit log table periodically.
-
-```
-	auditLogCtr.StartAuditLogPurger()
-```
 The Purge audit log should be implemented as job service type
 
 ```
@@ -162,12 +157,10 @@ func (j *AuditJob) Run(ctx job.Context, params job.Parameters) error {
 }
 ```
 
-The audit log purger could be implemented with jobservice, but it is might be complex and not easy to maintain.
-
 ### UI
 
-There is an audit log configurable page.
-It includes configure items:
+There is an audit log config in the main nativgation tree.
+It includes three tabs:
 
 ### Purge Job
 
@@ -196,7 +189,7 @@ If a user enable the option no audit log in database, then all audit log related
 
 ## Open issues (if applicable)
 
-The curren audit log implementation is syslog, it is not work as previous core.log or registry.log, which are log to stdout of the container. the audit log might need to configure separately in kubernetes.
+The current audit log implementation is syslog, it is not work as previous core.log or registry.log, which are log to stdout of the container. the audit log might need to configure separately in kubernetes.
 
 The schema of the audit_log will be changed in furture, users might have to change the query to get a specific information in LogViewer/LogInsight.