User guide for memory, execution, and proof.

Quick Start

Ausry Journal works best when you keep each surface honest. Journal captures what you were thinking. Cadence tracks what you said you would do. Research stores what you learned. Reports records what actually happened.

1. Open Journal and write one short entry when something changes: a decision, concern, event, or useful observation.
2. Use Long Document Note when the text is too large for a normal entry, such as a memo, report draft, or analysis.
3. Open Cadence when the entry becomes formal work that needs steps, owners, milestones, dates, blockers, or proof.
4. Work from Today whenever possible. Today should show the next small step, not the whole architecture.
5. Attach evidence before closing important work. A completion should explain what happened and why it counts.
6. Review weekly and monthly snapshots to see repeated problems, decisions, and context shifts without rereading everything.

Product Surfaces

Ausry Journal is a connected operating workspace. Each surface has a specific job.

Journal Entries

Journal is the fast input layer. Write normally, but include enough context that future you can understand the entry without guessing.

• Use dates, periods, projects, company names, owners, and sources when they matter.
• Write decisions in direct language: I decided..., We chose..., or The next step is....
• Use Long Document Note for essays, memos, report drafts, shareholder letters, acquisition notes, or long analyses.
• Do not turn Journal into a task manager. If the note becomes formal work, move that work into Cadence.

Cadence Basics

Cadence is the execution system. It converts a large goal into weekly and daily work that can be checked by evidence.

The mental model is:

Stage -> Gate -> Gate Plan -> Milestone -> Step -> Proof Packet -> Final Review

What Belongs In Cadence

• Build plans and plan hierarchy from long range objectives down to weekly steps.
• Stage gates that define what must be proven before a stage advances.
• Milestones and proof requirements that define verifiable outcomes.
• Routines, doctrine reviews, blockers, schedule changes, and completion notes.
• Activity log events that help explain what changed and when.

Recommended Cadence Flow

1. Create a clear parent plan with purpose, owner, dimensions, and success criteria.
2. Break it into year, quarter, month, week, and day layers only when that structure helps execution.
3. Use stages and gates when the plan should advance only after proof exists.
4. Ask Mechanic for the next weekly block when current work is complete, blocked, or ready for review.
5. Complete 1 to 3 strong weekly steps and attach evidence to each important step.
6. If work is blocked, explain what happened, why it happened, and how to prevent the same problem.

Proof Packets

A Proof Packet is the evidence attached to a Cadence step. Cadence should not count important work as complete just because someone wrote that it is done.

Evidence can be:

• A note explaining what was completed and why it counts.
• An internal document created from the step.
• A file or photo uploaded as evidence.
• A link with enough context to verify what it proves.
• A linked Journal entry when the entry itself is the relevant proof.

A step with required evidence should be completed only when the Proof Packet is present and the closing note explains the result.

Stage Gates

A stage does not advance by intention, by age, or by activity volume. A stage advances when its gates are proven.

Two Ways A Gate Can Close

1. Direct proof: the gate accepts a final evidence note directly.
2. Linked plan proof: a Gate Plan reaches 100%, has no blockers, has no missing proof, and is ready for final review.

Important rule: if a gate has a linked Gate Plan, the linked plan controls the gate. The final Prove action will wait until that plan is complete.

What Ready For Review Means

The Gate Plan is ready when its milestones, steps, and child work are verified, every required Proof Packet is complete, and no blockers or missing proof remain.

Cadence Mechanic

Mechanic is the diagnostic layer for Cadence. It should speak when there is a useful signal, not just because a new day started.

• It looks for active plans, delayed plans, blocked steps, overdue steps, missed milestones, weak success criteria, heavy routines, and repeated problems.
• When there is enough signal, it can propose 1 to 3 weekly steps with proof questions, acceptance criteria, why-now context, and failure signals.
• If there is no strong signal, a quiet result is correct.

Troubleshooting

Proof shows 1/1 but the step is not Done

Proof 1/1 means evidence exists. It does not always mean the step has been reviewed and completed. Open Review or Complete, check the evidence, add the closing note when needed, and submit the completion.

A gate refuses to close

Check whether the gate has a linked Gate Plan. If it does, complete the plan first. Review milestones, steps, blockers, and missing proof. When the plan reaches 100%, return to Gates and write the final gate review.

Today feels too complicated

Today should show the next useful step, not the full stage architecture. If too many items appear, reduce weekly focus to 1 to 3 strong items and close or block old work before generating new work.

Library is filling with formal plans

Move formal execution back to Cadence. Library can store reusable context and reminders, but plans with owners, steps, milestones, evidence, or gates belong in Cadence.

Privacy And AI Limits

Ausry Journal is designed for private operating context. There is no social feed, no follower graph, no public profile layer, and no ads layer.

• AI can help classify notes, retrieve context, summarize patterns, diagnose Cadence, and propose weekly blocks.
• AI does not replace final human judgment. Gate reviews, pass or fail decisions, and business conclusions remain human responsibilities.
• Support should focus on software issues, account problems, reproducible bugs, and stability, not reading private journal content.
• Exports and deletion controls should remain visible product requirements.