Most founders do not have a memory problem.

They have a decision problem.

The same judgment keeps returning in different clothes: Should we make an exception? Who can approve this? What happens when the customer asks for something outside the standard process? When should the AI act, and when should it stop?

You answer once in Slack, again in a meeting, and once more inside an AI chat. The work moves, but the decision disappears.

That is how a business becomes dependent on the founder's memory.

An AI co-founder needs more than access to your documents. It needs a clear record of the decisions that shape how the business operates.

Meeting notes tell you what people discussed. A task list tells you what someone should do next.

A decision log records the judgment that changes the system.

Log a decision when it affects a customer promise, a priority, a price, access to data, an approval boundary, a risk, or a recurring workflow rule.

Do not log every small choice. Capture the decisions your team or AI will need to reuse.

Every entry needs only five fields:

Imagine proposals are stalling because every draft returns to the founder.

The decision log might say:

Decision: Standard proposals can move without founder review. Pricing exceptions still require founder approval.

Why now: The standard proposal format is stable, but exception pricing still carries margin and promise risk.

Owner: Sales lead.

Rule: AI may prepare the standard proposal from approved inputs. It must stop when the request changes scope, price, legal terms, or delivery commitments.

Review date: Inspect the next set of proposals during the weekly operating review. Look for incorrect scope, unnecessary escalations, and promises the delivery team cannot keep.

This is not merely documentation. It is the bridge between a founder's judgment and a workflow the business can repeat safely.

First, it prevents the same debate from consuming the team every week.

Second, it makes AI output traceable. When the AI recommends an action, you can ask which rule and context shaped that recommendation.

Third, it reveals which decisions are stable enough to automate. A repeated judgment should become an explicit rule before it becomes an automated action.

Fourth, it exposes outdated policies. If nobody can explain why a rule exists, the rule needs review.

Once a week, spend 15 minutes on the log:

• Review the exceptions that reached a human.
• Update one unclear rule.
• Retire one rule whose context has expired.
• Turn one stable, low-risk rule into a reversible automation.
• Keep high-impact or irreversible decisions behind human approval.

If you already run a weekly review, connect the two rituals. The review shows where the system struggled; the decision log records how the system should behave next time.

Read the companion issue:
https://autopilot.heycora.in/p/ai-cofounder-weekly-operating-review

We are building Cora as a connected AI workspace that keeps work, context, ownership, and operating decisions together.

This issue describes an operating framework. It does not mean Cora currently ships a complete decision-log or automated policy-review feature. We will label released capabilities as released, experiments as experiments, and roadmap ideas as roadmap ideas.

Explore Cora:
https://heycora.in/

Choose one decision you made twice this month.

Write it as a rule. Name the owner. Add the approval boundary. Give it a review date.

Then ask: could another person—or an AI—apply this rule safely without calling me?

If the answer is no, the rule is not clear enough yet.

Reply and tell me: which decision keeps coming back to you?

— Dravya

This issue presents an operating framework, not a product-performance claim. We are not claiming that Cora currently runs this complete decision-log system. We will share measured workflow results when evidence is available.